| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <fujii(at)postgresql(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Crash in new pgstats code |
| Date: | 2022-04-18 07:18:52 |
| Message-ID: | Yl0Q3IZqH2CN2w4P@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Guo | 2022-04-18 07:35:53 | Fix NULL pointer reference in _outPathTarget() |
| Previous Message | Kyotaro Horiguchi | 2022-04-18 07:13:34 | Re: TRAP: FailedAssertion("tabstat->trans == trans", File: "pgstat_relation.c", Line: 508 |