Re: Should the archiver process always make sure that the timeline history files exist in the archive?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jimmy Yih <jyih(at)vmware(dot)com>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Should the archiver process always make sure that the timeline history files exist in the archive?
Date: 2024-01-05 19:35:23
Message-ID: CA+TgmoY6RaBKPwwp73a8Scv8iqNV37yxy-CqgKkbuLf6cQT_9Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 28, 2023 at 8:59 PM Jimmy Yih <jyih(at)vmware(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2024-01-05 19:40:05 Re: Unlogged relation copy is not fsync'd
Previous Message Andres Freund 2024-01-05 19:33:18 Re: the s_lock_stuck on perform_spin_delay