Re: Crash in new pgstats code - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Crash in new pgstats code
Date
Msg-id Yl0Q3IZqH2CN2w4P@paquier.xyz
Whole thread Raw
In response to Re: Crash in new pgstats code  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Sat, Apr 16, 2022 at 02:36:33PM -0700, Andres Freund wrote:
> which I haven't seen locally. Looks like we have some race between
> startup process and walreceiver? That seems not great.  I'm a bit
> confused that walreceiver and archiving are both active at the same time
> in the first place - that doesn't seem right as things are set up
> currently.

Yeah, that should be exclusively one or the other, never both.
WaitForWALToBecomeAvailable() would be a hot spot when it comes to
decide when a WAL receiver should be spawned by the startup process.
Except from the recent refactoring of xlog.c or the WAL prefetch work,
there has not been many changes in this area lately.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: TRAP: FailedAssertion("tabstat->trans == trans", File: "pgstat_relation.c", Line: 508
Next
From: Richard Guo
Date:
Subject: Fix NULL pointer reference in _outPathTarget()