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

From Andres Freund
Subject Re: Intermittent buildfarm failures on wrasse
Date
Msg-id B8178489-4414-4E0E-A74D-02267D4E9842@anarazel.de
Whole thread Raw
In response to Re: Intermittent buildfarm failures on wrasse  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Intermittent buildfarm failures on wrasse  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On April 15, 2022 2:14:47 PM EDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Andres Freund <andres@anarazel.de> writes:
>> On 2022-04-15 12:36:52 -0400, Tom Lane wrote:
>>> Yeah, I was also thinking about a flag in PGPROC being a more reliable
>>> way to do this.  Is there anything besides walsenders that should set
>>> that flag?
>
>> Not that I can think of. It's only because of hs_feedback that we need
>> to.  I guess it's possible that somebody build some extension that needs
>> something similar, but then they'd need to set that flag...
>
>Here's a WIP patch for that.  The only exciting thing in it is that
>because of some undocumented cowboy programming in walsender.c, the
>    Assert((proc->statusFlags & (~PROC_COPYABLE_FLAGS)) == 0);
>in ProcArrayInstallRestoredXmin fires unless we skip that.
>
>I could use some help filling in the XXX comments, because it's far
>from clear to me *why* walsenders need this to happen.

I'm out for the rest of the day due to family events (visiting my girlfriend's parents till Wednesday), I can take a
stabat formulating something after.  

If you want to  commit before: The reason is that walsenders use their xmin to represent the xmin of standbys when
usinghot_standby_feedback. Since we're only transmitting global horizons up from standbys, it has to influence globally
(andit would be hard to represent per db horizons anyway). 

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Intermittent buildfarm failures on wrasse
Next
From: Ilaria Battiston
Date:
Subject: Re: GSOC: New and improved website for pgjdbc (JDBC) (2022)