Fix function names in comments.

Commit 3eb77eba5a renamed some functions, but forgot to
update some comments referencing to those functions.
This commit fixes those function names in the comments.

Kyotaro Horiguchi
This commit is contained in:
Fujii Masao 2019-04-25 23:43:48 +09:00
parent 87259588d0
commit 978b032d1f
4 changed files with 7 additions and 7 deletions

View file

@ -137,7 +137,7 @@ typedef struct
static CheckpointerShmemStruct *CheckpointerShmem;
/* interval for calling AbsorbFsyncRequests in CheckpointWriteDelay */
/* interval for calling AbsorbSyncRequests in CheckpointWriteDelay */
#define WRITES_PER_ABSORB 1000
/*

View file

@ -952,7 +952,7 @@ register_forget_request(RelFileNodeBackend rnode, ForkNumber forknum,
}
/*
* ForgetDatabaseFsyncRequests -- forget any fsyncs and unlinks for a DB
* ForgetDatabaseSyncRequests -- forget any fsyncs and unlinks for a DB
*/
void
ForgetDatabaseSyncRequests(Oid dbid)

View file

@ -75,7 +75,7 @@ static MemoryContext pendingOpsCxt; /* context for the above */
static CycleCtr sync_cycle_ctr = 0;
static CycleCtr checkpoint_cycle_ctr = 0;
/* Intervals for calling AbsorbFsyncRequests */
/* Intervals for calling AbsorbSyncRequests */
#define FSYNCS_PER_ABSORB 10
#define UNLINKS_PER_ABSORB 10
@ -215,9 +215,9 @@ SyncPostCheckpoint(void)
pfree(entry);
/*
* As in ProcessFsyncRequests, we don't want to stop absorbing fsync
* As in ProcessSyncRequests, we don't want to stop absorbing fsync
* requests for along time when there are many deletions to be done.
* We can safely call AbsorbFsyncRequests() at this point in the loop
* We can safely call AbsorbSyncRequests() at this point in the loop
* (note it might try to delete list entries).
*/
if (--absorb_counter <= 0)
@ -284,7 +284,7 @@ ProcessSyncRequests(void)
* eventually wrap the counter around to the point where an old entry
* might appear new, causing us to skip it, possibly allowing a checkpoint
* to succeed that should not have. To forestall wraparound, any time the
* previous ProcessFsyncRequests() failed to complete, run through the
* previous ProcessSyncRequests() failed to complete, run through the
* table and forcibly set cycle_ctr = sync_cycle_ctr.
*
* Think not to merge this loop with the main loop, as the problem is

View file

@ -68,7 +68,7 @@ rmtree(const char *path, bool rmtopdir)
* This is not an academic possibility. One scenario where this
* happens is when bgwriter has a pending unlink request for a file in
* a database that's being dropped. In dropdb(), we call
* ForgetDatabaseFsyncRequests() to flush out any such pending unlink
* ForgetDatabaseSyncRequests() to flush out any such pending unlink
* requests, but because that's asynchronous, it's not guaranteed that
* the bgwriter receives the message in time.
*/