Re: .ready and .done files considered harmful - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: .ready and .done files considered harmful
Date
Msg-id CF7D0ECB-EEFF-4E76-8963-8A3648AD9052@amazon.com
Whole thread Raw
In response to Re: .ready and .done files considered harmful  (Dipesh Pandit <dipesh.pandit@gmail.com>)
List pgsql-hackers
+     * This .ready file is created out of order, notify archiver to perform
+     * a full directory scan to archive corresponding WAL file.
+     */
+    StatusFilePath(archiveStatusPath, xlog, ".ready");
+    if (stat(archiveStatusPath, &stat_buf) == 0)
+        PgArchEnableDirScan();

We may want to call PgArchWakeup() after setting the flag.

+     * Perform a full directory scan to identify the next log segment. There
+     * may be one of the following scenarios which may require us to perform a
+     * full directory scan.
...
+     * - The next anticipated log segment is not available.

I wonder if we really need to perform a directory scan in this case.
Unless there are other cases where the .ready files are created out of
order, I think this just causes an unnecessary directory scan every
time the archiver catches up.

+     * Flag to enable/disable directory scan. If this flag is set then it
+     * forces archiver to perform a full directory scan to get the next log
+     * segment.
+     */
+    pg_atomic_flag dirScan;

I personally don't think it's necessary to use an atomic here.  A
spinlock or LWLock would probably work just fine, as contention seems
unlikely.  If we use a lock, we also don't have to worry about memory
barriers.

Nathan


pgsql-hackers by date:

Previous
From: Soumyadeep Chakraborty
Date:
Subject: Re: Changes to recovery_min_apply_delay are ignored while waiting for delay
Next
From: "Bossart, Nathan"
Date:
Subject: Re: .ready and .done files considered harmful