Re: oldest/newestCommitTs output by pg_controldata - Mailing list pgsql-hackers

From Joe Conway
Subject Re: oldest/newestCommitTs output by pg_controldata
Date
Msg-id 56816989.2070004@joeconway.com
Whole thread Raw
In response to Re: oldest/newestCommitTs output by pg_controldata  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: oldest/newestCommitTs output by pg_controldata  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 12/26/2015 06:32 PM, Michael Paquier wrote:
> On Sun, Dec 27, 2015 at 10:08 AM, Joe Conway <mail@joeconway.com> wrote:
>> In looking at the exposing pg_controldata as function patch again, it
>> struck me that the following output seems wrong:
>>
>> --------------
>> Latest checkpoint's oldestCommitTs:   20257
>> Latest checkpoint's newestCommitTs:   84159
>> --------------
>>
>> Those numbers are XIDs, not timestamps. Shouldn't we either emit the
>> actual timestamps, or else rename those to oldest/newestCommitXID?
>
> I recall from the commit_ts thread that Alvaro had some real need to
> make those fields XIDs and not timestamps, so +1 for renaming that as
> suggested.

Ok, but now next question -- should we just change the user visible
output to oldestCommitXID/newestCommitXID, or should we change the
variable name everywhere it appears in source as well? Looks like each
one appears about 25-30 times scattered across 9 or 10 files. Since they
are new in 9.5, if we're going to change them, I'd think we ought to do
it now or never.

If there is consensus to make the change either way (output-only or
globally), I'll come up with a patch ASAP.

Opinions?

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_upgrade tests running calling psql without --no-psqlrc
Next
From: Tom Lane
Date:
Subject: Re: oldest/newestCommitTs output by pg_controldata