Re: BUG #17146: pg_dump statements are going into pg_stat_statements in 13.4

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: BUG #17146: pg_dump statements are going into pg_stat_statements in 13.4
Дата
Msg-id CAOBaU_YFnWjqpkw7jQCB2J-FQNyPbFj_YQRpsuj6Z16Na+5A_g@mail.gmail.com
обсуждение исходный текст
Ответ на BUG #17146: pg_dump statements are going into pg_stat_statements in 13.4  (PG Bug reporting form <noreply@postgresql.org>)
Список pgsql-bugs
On Mon, Aug 16, 2021 at 5:48 PM James Inform <james.inform@pharmapp.de> wrote:
>
> That's strange.
> I see those copy commands it pg_stat_statments and they have 1 calls.
> The backup job runs once a day since many months. I would expect to see
> calls > 1 then.

One possibility is that pg_stat_statements.max is too small, leading
to pg_stat_statements evicting the least frequently used entries.  You
can compare the current number of entries to the
pg_stat_statements.max and see if it has between 95 and 100% of
entries allocated.

Note that pg_stat_statements entry eviction is quite costly, so if
that the reason why you don't see more execution you may want to
increase pg_stat_statements.max.  It might not be an option if you
have hundred of thousands of tables though, and in that case disabling
track_utility may be a better option.  Another good option may also be
to change you backup approach and rely on physical backup rather than
pg_dump, which would solve your original problem and also probably
improve your RPO.



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

Предыдущее
От: James Inform
Дата:
Сообщение: Re: BUG #17146: pg_dump statements are going into pg_stat_statements in 13.4
Следующее
От: James Inform
Дата:
Сообщение: Re: BUG #17145: Invalid memory alloc request size, when searching in text column with big content > 250MB