Re: Show various offset arrays for heap WAL records

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Show various offset arrays for heap WAL records
Дата
Msg-id CAH2-Wz=jurx-Xo=LKCQVtRLJ4=Di5cGh4fT-bLEirC40-jDOMA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Show various offset arrays for heap WAL records  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: Show various offset arrays for heap WAL records  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Tue, Jan 31, 2023 at 1:52 PM Peter Geoghegan <pg@bowt.ie> wrote:
> Obviously what you're doing here will lead to a significant increase
> in the verbosity of the output for affected WAL records. I don't feel
> too bad about that, though. It's really an existing problem, and one
> that should be fixed either way. You kind of have to deal with this
> already, by having a good psql pager, since record types such as
> COMMIT_PREPARED, INVALIDATIONS, and RUNNING_XACTS are already very
> verbose in roughly the same way. You only need to have one of these
> record types output by a function like pg_get_wal_records_info() to
> get absurdly wide output -- it hardly matters that most individual WAL
> record types have terse output at that point.

Actually the really wide output comes from COMMIT records. After I run
the regression tests, and execute some of my own custom pg_walinspect
queries, I see that some individual COMMIT records have a
length(description) of over 10,000 bytes/characters. There is even one
particular COMMIT record whose length(description) is about 46,000
bytes/characters. So *ludicrously* verbose GetRmgr() strings are not
uncommon today. The worst case (or even particularly bad cases) won't
be made any worse by this patch, because there are obviously limits on
the width of the arrays that it outputs details descriptions of, that
don't apply to these COMMIT records.

-- 
Peter Geoghegan



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

Предыдущее
От: Peter Smith
Дата:
Сообщение: Re: Logical replication timeout problem
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: recovery modules