Re: Inconsitancies in pg_stat_bgwriter and pg_stat_database returned values

Поиск
Список
Период
Сортировка
От RECHTÉ Marc
Тема Re: Inconsitancies in pg_stat_bgwriter and pg_stat_database returned values
Дата
Msg-id 746448376.8762238.1600324690698.JavaMail.zimbra@meteo.fr
обсуждение исходный текст
Ответ на Re: Inconsitancies in pg_stat_bgwriter and pg_stat_database returned values  (Jehan-Guillaume de Rorthais <jgdr@dalibo.com>)
Ответы Re: Inconsitancies in pg_stat_bgwriter and pg_stat_database returned values  (Jehan-Guillaume de Rorthais <jgdr@dalibo.com>)
Список pgsql-bugs
On Wed, 16 Sep 2020 17:06:45 +0200 (CEST)
RECHTÉ Marc <marc.rechte@meteo.fr> wrote:

> Hello,
>
> On one particular PG12.3 instance (same behaviour with PG12.4) we are
> experimenting occasional strange values in the above tables.
>
> For instance looping (10s. period) over this request:
>
> SELECT current_timestamp, checkpoints_timed,
> checkpoints_req,
> checkpoint_write_time,
> checkpoint_sync_time,
> buffers_checkpoint,
> buffers_clean,
> maxwritten_clean,
> buffers_backend,
> buffers_backend_fsync,
> buffers_alloc
> FROM pg_stat_bgwriter
>
> Gives:  [...]
>
> One can see that some columns that are supposed to increase only are not
> always. For instance checkpoints_timed suddenly jumps from 438 to 3291, then
> back to 438.
>
> We experiment the same issue in pg_stat_database.


----- Mail original -----
De: "Jehan-Guillaume de Rorthais" <jgdr@dalibo.com>
À: "RECHTÉ Marc" <marc.rechte@meteo.fr>
Cc: pgsql-bugs@lists.postgresql.org
Envoyé: Mercredi 16 Septembre 2020 17:31:24
Objet: Re: Inconsitancies in pg_stat_bgwriter and pg_stat_database returned values

The full row are different in your example, not just a few fields. It looks
like mixed values from different instance.

Could you share some more informations about the context and how to reproduce
it?

Regards,

Hello

Thanks a lot, you got it right: there are 2 instances on this machine and they are both configured with:

stats_temp_directory = '/dev/shm'

We some time ago tried, stats_temp_directory = '/dev/shm/instance', but PostgreSQL ignored the subdirectory part and
keptcreating the temp file at the FS root. 
As this is a temporary FS, one cannot in advance create the instance subdirectory as it is wiped out between reboots.

Best regards



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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Strange output of XML attribute values
Следующее
От: Jehan-Guillaume de Rorthais
Дата:
Сообщение: Re: Inconsitancies in pg_stat_bgwriter and pg_stat_database returned values