On Mon, Aug 28, 2023 at 8:59 PM Jimmy Yih <j...@vmware.com> wrote: > Thanks for the insightful response! I have attached an updated patch > that moves the proposed logic to the end of StartupXLOG where it seems > more correct to do this. It also helps with backporting (if it's > needed) since the archiver process only has access to shared memory > starting from Postgres 14.
Hmm. Do I understand correctly that the two patches you attached are alternatives to each other, i.e. we need one or the other to fix the issue, but not both? It seems to me that trying to fetch a timeline history file and then ignoring any error has got to be wrong. Either the file is needed or it isn't. If it's needed, then failing to fetch it is a problem. If it's not needed, there's no reason to try fetching it in the first place. So I feel like we could either try to archive the file at the end of recovery, as you propose in v2-0001-Archive-current-timeline-history-file-after-recovery.patch. Alternatively, we could try to find a way not to request the file in the first place, if it's not required. But v1-0001-Allow-recovery-to-proceed-when-initial-timeline-hist.patch doesn't seem good to me. -- Robert Haas EDB: http://www.enterprisedb.com
