Re: Session WAL activity

Поиск
Список
Период
Сортировка
Искать
От
Michael Paquier
Тема
Re: Session WAL activity
Дата
Msg-id
20191206015714.GH121835@paquier.xyz
Ответ на
Re: Session WAL activity (Konstantin Knizhnik)
Список
Дерево обсуждения
Session WAL activity Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Re: Session WAL activity Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Re: Session WAL activity Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Re: Session WAL activity Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Re: Session WAL activity Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Re: Session WAL activity Michael Paquier <michael@paquier.xyz>
Re: Session WAL activity Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Re: Session WAL activity Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Re: Session WAL activity Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Re: Session WAL activity Craig Ringer <craig@2ndquadrant.com>
Re: Session WAL activity Bruce Momjian <bruce@momjian.us>
Re: Session WAL activity Andres Freund <andres@anarazel.de>
On Thu, Dec 05, 2019 at 12:23:40PM +0300, Konstantin Knizhnik wrote:
> Concerning keeping PGPROC size as small as possible, I agree that it is
> reasonable argument.
> But even now it is very large (816 bytes) and adding extra 8 bytes will
> increase it on less than 1%.

It does not mean that we should add all kind of things to PGPROC as
that's a structure sensitive enough already.  By the way, why do you 
assume that 8-byte reads are always safe and atomic in the patch?

> Right now pg_stat_activity also accessing PGPROC to obtain wait event
> information and also not taking any locks.
> So it can wrongly report backend status. But I never heard that somebody
> complains about it.

Please see pgstat.h, close to pgstat_report_wait_start().
--
Michael
В списке pgsql-hackers по дате отправления
От: Michael Paquier
Дата:
От: Dilip Kumar
Дата:
FAQ