From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: using an end-of-recovery record in all cases |
Date: | 2021-09-02 15:30:59 |
Message-ID: | CA+Tgmob10roZ8K2A0e11782Vc+TveN5anPrS6R0j8fZixppJsg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 9, 2021 at 3:00 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I decided to try writing a patch to use an end-of-recovery record
> rather than a checkpoint record in all cases.
>
> The first problem I hit was that GetRunningTransactionData() does
> Assert(TransactionIdIsNormal(CurrentRunningXacts->latestCompletedXid)).
>
> Unfortunately we can't just relax the assertion, because the
> XLOG_RUNNING_XACTS record will eventually be handed to
> ProcArrayApplyRecoveryInfo() for processing ... and that function
> contains a matching assertion which would in turn fail. It in turn
> passes the value to MaintainLatestCompletedXidRecovery() which
> contains yet another matching assertion, so the restriction to normal
> XIDs here looks pretty deliberate. There are no comments, though, so
> the reader is left to guess why. I see one problem:
> MaintainLatestCompletedXidRecovery uses FullXidRelativeTo, which
> expects a normal XID. Perhaps it's best to just dodge the entire issue
> by skipping LogStandbySnapshot() if latestCompletedXid happens to be
> 2, but that feels like a hack, because AFAICS the real problem is that
> StartupXLog() doesn't agree with the rest of the code on whether 2 is
> a legal case, and maybe we ought to be storing a value that doesn't
> need to be computed via TransactionIdRetreat().
Anyone have any thoughts about this?
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Ronan Dunklau | 2021-09-02 15:34:59 | Re: improve pg_receivewal code |
Previous Message | Robert Haas | 2021-09-02 15:28:27 | Re: replay of CREATE TABLESPACE eats data at wal_level=minimal |