Re: Feature improvement: can we add queryId forpg_catalog.pg_stat_activity view?
От | Andres Freund |
---|---|
Тема | Re: Feature improvement: can we add queryId forpg_catalog.pg_stat_activity view? |
Дата | |
Msg-id | 20190802232048.lpj43ju6obnl42tv@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activityview? (Julien Rouhaud <julien.rouhaud@free.fr>) |
Ответы |
Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activityview?
|
Список | pgsql-hackers |
Hi, On 2019-08-02 10:54:35 +0200, Julien Rouhaud wrote: > On Thu, Aug 1, 2019 at 11:05 PM Andres Freund <andres@anarazel.de> wrote: > > > > I'm actually quite unconvinced that it's sensible to update the global > > value for nested queries. That'll mean e.g. the log_line_prefix and > > pg_stat_activity values are most of the time going to be bogus while > > nested, because the querystring that's associated with those will *not* > > be the value that the queryid corresponds to. elog.c uses > > debug_query_string to log the statement, which is only updated for > > top-level queries (outside of some exceptions like parallel workers for > > parallel queries in a function or stuff like that). And pg_stat_activity > > is also only updated for top level queries. > > Having the nested queryid seems indeed quite broken for > log_line_prefix. However having the nested queryid in > pg_stat_activity would be convenient to track what is a long stored > functions currently doing. Maybe we could expose something like > top_level_queryid and current_queryid instead? Given that the query string is the toplevel one, I think that'd just be confusing. And given the fact that it adds *substantial* additional complexity, I'd just rip the subcommand bits out. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: