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

From Andres Freund
Subject Re: elog.c query_id support vs shutdown
Date
Msg-id 20210808190616.xbich5e42tzy7si7@alap3.anarazel.de
Whole thread Raw
In response to Re: elog.c query_id support vs shutdown  (Andres Freund <andres@anarazel.de>)
Responses Re: elog.c query_id support vs shutdown  (Julien Rouhaud <rjuju123@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: elog.c query_id support vs shutdown
Next
From: Peter Geoghegan
Date:
Subject: Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE