Comment fix for renamed functions

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Comment fix for renamed functions
Дата
Msg-id 20190425.185028.126780684.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответы Re: Comment fix for renamed functions  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers
Hello.

I happened to find that several symbols renamed in 3eb77eba5a are
left in comments. Please find the attached.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

diff --git a/src/backend/postmaster/checkpointer.c b/src/backend/postmaster/checkpointer.c
index a1e04239ad..13f152b473 100644
--- a/src/backend/postmaster/checkpointer.c
+++ b/src/backend/postmaster/checkpointer.c
@@ -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
 
 /*
diff --git a/src/backend/storage/smgr/md.c b/src/backend/storage/smgr/md.c
index 61a8f11469..52ca6eeb28 100644
--- a/src/backend/storage/smgr/md.c
+++ b/src/backend/storage/smgr/md.c
@@ -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)
diff --git a/src/backend/storage/sync/sync.c b/src/backend/storage/sync/sync.c
index f77519d7d1..096735c807 100644
--- a/src/backend/storage/sync/sync.c
+++ b/src/backend/storage/sync/sync.c
@@ -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
diff --git a/src/common/rmtree.c b/src/common/rmtree.c
index 3052d013ee..b31da3adff 100644
--- a/src/common/rmtree.c
+++ b/src/common/rmtree.c
@@ -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.
          */

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Regression test PANICs with master-standby setup on samemachine
Следующее
От: Shaoqi Bai
Дата:
Сообщение: Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6