Re: elog.c query_id support vs shutdown

From: Andres Freund <andres(at)anarazel(dot)de>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: elog.c query_id support vs shutdown
Date: 2021-08-08 19:06:16
Message-ID: 20210808190616.xbich5e42tzy7si7@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2021-08-08 11:53:39 -0700, Andres Freund wrote:
> On 2021-08-08 13:46:39 +0800, Julien Rouhaud wrote:
> > > I suspect that to make the elog.c usage safe, we'll have to clear MyBEEntry in
> > > pgstat_beshutdown_hook().
> >
> > I agree, and a quick test indeed fix your scenario. It also seems like a good
> > thing to do overall.
>
> Yea, it does seem like a good thing. But we should do a search for the
> problems it could cause...

Not a problem with unsetting MyBEEntry. But the search for problems made me
reread the following comment:

/*
* There's no need for a lock around pgstat_begin_read_activity /
* pgstat_end_read_activity here as it's only called from
* pg_stat_get_activity which is already protected, or from the same
* backend which means that there won't be concurrent writes.
*/

I don't understand the pg_stat_get_activity() part of this comment?
pgstat_get_my_query_id() hardcodes MyBEEntry->st_query_id, so it can't be
useful to pg_stat_get_activity(), nor is it used there?

I assume it's just a remnant from an earlier iteration of the code?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-08-08 19:48:44 Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE
Previous Message Andres Freund 2021-08-08 18:53:39 Re: elog.c query_id support vs shutdown