Re: Standardizing how pg_waldump presents recovery conflict XID cutoffs
От | Andres Freund |
---|---|
Тема | Re: Standardizing how pg_waldump presents recovery conflict XID cutoffs |
Дата | |
Msg-id | 20221117002521.c7h2leaq6npsqctc@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Standardizing how pg_waldump presents recovery conflict XID cutoffs (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Standardizing how pg_waldump presents recovery conflict XID cutoffs
|
Список | 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 по дате отправления: