Re: Intermittent buildfarm failures on wrasse - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Intermittent buildfarm failures on wrasse
Date
Msg-id 202205141453.skp37viold2x@alvherre.pgsql
Whole thread Raw
In response to Intermittent buildfarm failures on wrasse  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Intermittent buildfarm failures on wrasse
List pgsql-hackers
On 2022-Apr-20, Masahiko Sawada wrote:

> >     MyProc->statusFlags = (MyProc->statusFlags & ~PROC_XMIN_FLAGS) |
> >                           (proc->statusFlags & PROC_XMIN_FLAGS);
> >
> > Perhaps the latter is more future-proof.

> Copying only xmin-related flags in this way also makes sense to me and
> there is no problem at least for now. A note would be that when we
> introduce a new flag that needs to be copied in the future, we need to
> make sure to add it to PROC_XMIN_FLAGS so it is copied. Otherwise a
> similar issue we fixed by 0f0cfb494004befb0f6e could happen again.

OK, done this way -- patch attached.

Reading the comment I wrote about it, I wonder if flags
PROC_AFFECTS_ALL_HORIZONS and PROC_IN_LOGICAL_DECODING should also be
included.  I think the only reason we don't care at this point is that
walsenders (logical or otherwise) do not engage in snapshot copying.
But if we were to implement usage of parallel workers sharing a common
snapshot to do table sync in parallel, then it ISTM it would be
important to copy at least the latter.  Not sure there are any cases
were we might care about the former.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"Every machine is a smoke machine if you operate it wrong enough."
https://twitter.com/libseybieda/status/1541673325781196801

Attachment

pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Skipping schema changes in publication
Next
From: Bruce Momjian
Date:
Subject: Re: First draft of the PG 15 release notes