Re: Show various offset arrays for heap WAL records - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Show various offset arrays for heap WAL records
Date
Msg-id CAH2-WzkbYuvwYKm-Y-72QEh6SPMQcAo9uONv+mR3bMGcu9E_Cg@mail.gmail.com
Whole thread Raw
In response to Re: Show various offset arrays for heap WAL records  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Show various offset arrays for heap WAL records  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Fri, Apr 7, 2023 at 4:46 PM Peter Geoghegan <pg@bowt.ie> wrote:
> Pushed that one too.

I noticed that the nbtree VACUUM and DELETE record types have their
update/xl_btree_update arrays output incorrectly. We cannot use the
generic array_desc() approach with xl_btree_update elements, because
they're variable-width elements. The problem is that array_desc() only deals
with fixed-width elements.

I also changed some of the details around whitespace in arrays in the
fixup patch (though I didn't do the same with objects). It doesn't
seem useful to use so much whitespace for long arrays of integers
(really page offset numbers). And I brought a few nbtree desc routines
that still used ";" characters as punctuation in line with the new
convention.

Finally, the patch revises the guidelines written for rmgr desc
routine authors. I don't think that we need to describe how to handle
outputting whitespace in detail. It'll be quite natural for other
rmgrs to use existing facilities such as array_desc() themselves,
which makes whitespace type inconsistencies unlikely. I've tried to
make the limits of the guidelines clear. The main goal is to avoid
gratuitous inconsistencies, and to provide a standard way of doing
things that many different rmgrs are likely to want to do, again and
again. But individual rmgrs still have a certain amount of discretion,
which seems like a good thing to me (the alternative requires that we
fix at least a couple of things in nbtdesc.c and in heapdesc.c, which
doesn't seem useful to me).

--
Peter Geoghegan

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Commitfest 2023-03 starting tomorrow!
Next
From: Greg Stark
Date:
Subject: Re: Commitfest 2023-03 starting tomorrow!