From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Dipesh Pandit <dipesh(dot)pandit(at)gmail(dot)com> |
Cc: | Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Hannu Krosing <hannuk(at)google(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: .ready and .done files considered harmful |
Date: | 2021-08-03 20:46:57 |
Message-ID: | 32FCEE06-C094-4B3F-BA6A-CCAF90FB90E2@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
+ /*
+ * 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.
+ *
+ * 1. This is the first cycle since archiver has started and there is no
+ * idea about the next anticipated log segment.
+ *
+ * 2. There is a timeline switch, i.e. the timeline ID tracked at archiver
+ * does not match with current timeline ID. Archive history file as part of
+ * this timeline switch.
+ *
+ * 3. The next anticipated log segment is not available.
One benefit of the current implementation of pgarch_readyXlog() is
that .ready files created out of order will be prioritized before
segments with greater LSNs. IIUC, with this patch, as long as there
is a "next anticipated" segment available, the archiver won't go back
and archive segments it missed. I don't think the archive status
files are regularly created out of order, but XLogArchiveCheckDone()
has handling for that case, and the work to avoid creating .ready
files too early [0] seems to make it more likely. Perhaps we should
also force a directory scan when we detect that we are creating a
.ready file for a segment that is older than the "next anticipated"
segment.
Nathan
[0] https://postgr.es/m/DA71434B-7340-4984-9B91-F085BC47A778%40amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2021-08-03 20:59:24 | Re: Reduce lock level for ALTER TABLE ... ADD CHECK .. NOT VALID |
Previous Message | Greg Stark | 2021-08-03 20:22:16 | Re: Commitfest overflow |