Re: Show various offset arrays for heap WAL records

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Show various offset arrays for heap WAL records
Date: 2023-01-31 23:19:39
Message-ID: CAH2-Wz=jurx-Xo=LKCQVtRLJ4=Di5cGh4fT-bLEirC40-jDOMA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 31, 2023 at 1:52 PM Peter Geoghegan <pg(at)bowt(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2023-01-31 23:30:13 Re: recovery modules
Previous Message Peter Smith 2023-01-31 23:13:19 Re: Logical replication timeout problem