Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activityview?

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activityview?
Дата
Msg-id CAOBaU_aYoAR8m3K91D6PcUT=wzUATfiGJ1mAxMZ8Oo2094f6ow@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activityview?  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activityview?  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers
On Tue, Mar 19, 2019 at 3:51 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
>
> On Mon, Mar 18, 2019 at 7:33 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
> >
> > On Mon, Mar 18, 2019 at 6:23 PM Yun Li <liyunjuanyong@gmail.com> wrote:
> > >
> > > Let's take one step back. Since queryId is stored in core as Julien pointed out, can we just add that global to
thepg_stat_get_activity and ultimately exposed in pg_stat_activity view? Then no matter whether PGSS  is on or off, or
howeverthe customer extensions are updating that filed, we expose that field in that view then enable user to leverage
thatid to join with pgss or their extension. Will this sounds a good idea? 
> >
> > I'd greatly welcome expose queryid exposure in pg_stat_activity, and
> > also in log_line_prefix.  I'm afraid that it's too late for pg12
> > inclusion, but I'll be happy to provide a patch for that for pg13.
>
> Here's a prototype patch for queryid exposure in pg_stat_activity and
> log_line prefix.

Patch doesn't apply anymore, PFA rebased v2.

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Superfluous libpq-be.h include in GSSAPI code
Следующее
От: Luis Carril
Дата:
Сообщение: Option to dump foreign data in pg_dump