Re: Standardizing how pg_waldump presents recovery conflict XID cutoffs - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Standardizing how pg_waldump presents recovery conflict XID cutoffs
Date
Msg-id 20221117002521.c7h2leaq6npsqctc@awork3.anarazel.de
Whole thread Raw
In response to Re: Standardizing how pg_waldump presents recovery conflict XID cutoffs  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Standardizing how pg_waldump presents recovery conflict XID cutoffs
List pgsql-hackers
Hi,

On 2022-11-16 15:37:40 -0800, Peter Geoghegan wrote:
> On Wed, Nov 16, 2022 at 3:27 PM Andres Freund <andres@anarazel.de> wrote:
> > What are "snapshotConflictHorizon format XIDs"? I guess you mean format in the
> > sense of having the semantics of snapshotConflictHorizon?
> 
> Yes. That is the only possible way that any recovery conflict ever
> works on the REDO side, with the exception of a few
> not-very-interesting cases such as DROP TABLESPACE.
> 
> GetConflictingVirtualXIDs() assigns a special meaning to
> InvalidTransactionId which is the *opposite* of the special meaning
> that snapshotConflictHorizon-based values assign to
> InvalidTransactionId. At one point they actually did the same
> definition for InvalidTransactionId, but that was changed soon after
> hot standby first went in (when we taught btree delete records to not
> use ludicrously conservative cutoffs that caused needless conflicts).
> 
> Anyway, worth calling this out directly in these comments IMV. We're
> addressing two closely related things that assign opposite meanings to
> InvalidTransactionId, which is rather confusing.

It makes sense to call this out, but I'd
s/snapshotConflictHorizon format XIDs/cutoff with snapshotConflictHorizon semantics/

or such?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: About displaying NestLoopParam
Next
From: Andrey Borodin
Date:
Subject: Re: libpq compression (part 2)