Re: elog.c query_id support vs shutdown - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: elog.c query_id support vs shutdown
Date
Msg-id CAOBaU_a6iRbLDEV9+Y+iuKC2hMmYDtcZfn35Xp9gKs4NB3MFjA@mail.gmail.com
Whole thread Raw
In response to Re: elog.c query_id support vs shutdown  (Michael Paquier <michael@paquier.xyz>)
Responses Re: elog.c query_id support vs shutdown  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Thu, Aug 19, 2021 at 3:05 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> The thread of this open item is now idle for 10 days and there does
> not seem to be a lot of progress.  Bruce, this is assigned to you.
> Are you planning to look at it?

I'm really sorry for the lack of answer on my side, I had too many
duties at work to thoroughly look at the implication of clearing
MyBEEntry in the pgstat_beshutdown_hook :(

With what I've seen so far I didn't find any evidence that it could
lead to any new problem (it should actually make things slightly
safer) and couldn't hit any issue with some testing.  Opinion from
someone more familiar with pgstats is of course welcome.

While reading the various code, I also found this incorrect comment in
backend_status.c:

/* exposed so that progress.c can access it */
PgBackendStatus *MyBEEntry = NULL;

progress.c was apparently renamed to backend_progress.c sometime
during e1025044 development (Split backend status and progress related
functionality out of pgstat.c.).

So I'm +1 for the fix originally suggested by Andres.



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Skipping logical replication transactions on subscriber side
Next
From: Greg Nancarrow
Date:
Subject: Re: Skipping logical replication transactions on subscriber side