On Mon, Jan 4, 2021 at 2:06 PM Peter Geoghegan wrote:
> Right. Self-consistency matters, as does consistency with the source
> code itself.
Pushed a commit that standardizes on the name latestRemovedXid within
rmgr desc output routines just now.
Thanks
--
Peter Geoghegan
On Sun, Jan 3, 2021 at 8:58 PM Masahiko Sawada wrote:
> On Mon, Jan 4, 2021 at 12:55 PM Peter Geoghegan wrote:
> +1 for changing heapdesc.c on master. It's not only readable but also
> consistent with other *desc showing the field named latestRemovedXid.
> For instance, nbtdesc.c has:
>
>
On Mon, Jan 4, 2021 at 1:12 PM Andres Freund wrote:
> I personally mildly prefer remxid - anything that is understandable but
> shortens the line length is good for my uses of waldump.
I want to use latestRemovedXid here because it is quite recognizable
to me as a symbol name. It appears as a sym
Hi,
On 2021-01-03 19:54:38 -0800, Peter Geoghegan wrote:
> I notice that heapdesc.c outputs the field latestRemovedXid as
> "remxid". But why? What sense is there in changing the name for output
> by tools like pg_waldump, which are intrinsically internals focussed?
I personally mildly prefer rem
At 2021-01-03 19:54:38 -0800, p...@bowt.ie wrote:
>
> It just seems worth removing gratuitous inconsistencies,
> such as this one.
Agreed.
-- Abhijit
On Mon, Jan 4, 2021 at 12:55 PM Peter Geoghegan wrote:
>
> I notice that heapdesc.c outputs the field latestRemovedXid as
> "remxid". But why? What sense is there in changing the name for output
> by tools like pg_waldump, which are intrinsically internals focussed?
Not sure but it has been "remx
