Re: tracking commit timestamps - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: tracking commit timestamps
Date
Msg-id 54635B61.4050106@2ndquadrant.com
Whole thread Raw
In response to Re: tracking commit timestamps  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: tracking commit timestamps  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: tracking commit timestamps  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On 10/11/14 14:53, Robert Haas wrote:
> On Mon, Nov 10, 2014 at 8:39 AM, Petr Jelinek <petr@2ndquadrant.com> wrote:
>> I did the calculation above wrong btw, it's actually 20 bytes not 24 bytes
>> per record, I am inclined to just say we can live with that.
>
> If you do it as 20 bytes, you'll have to do some work to squeeze out
> the alignment padding.  I'm inclined to think it's fine to have a few
> extra padding bytes here; someone might want to use those for
> something in the future, and they probably don't cost much.
>

I did get around the alignment via memcpy, so it is still 20bytes.

>> Since we agreed that the (B) case is not really feasible and we are doing
>> the (C), I also wonder if extradata should be renamed to nodeid (even if
>> it's not used at this point as nodeid). And then there is question about the
>> size of it, since the nodeid itself can live with 2 bytes probably ("64k of
>> nodes ought to be enough for everybody" ;) ).
>> Or leave the extradata as is but use as reserved space for future use and
>> not expose it at this time on SQL level at all?
>
> I vote for calling it node-ID, and for allowing at least 4 bytes for
> it.  Penny wise, pound foolish.
>

Ok, I went this way.

Anyway here is v8 version of the patch, I think I addressed all the
concerns mentioned, it's also rebased against current master (BRIN
commit added some conflicts).

Brief list of changes:
  - the commit timestamp record now stores timestamp, lsn and nodeid
  - added code to disallow turning track_commit_timestamp on with too
small pagesize
  - the get interfaces error out when track_commit_timestamp is off
  - if the xid passed to get interface is out of range -infinity
timestamp is returned (I think it's bad idea to throw errors here as the
valid range is not static and same ID can start throwing errors between
calls theoretically)
  - renamed the sql interfaces to pg_xact_commit_timestamp,
pg_xact_commit_timestamp_data and pg_last_committed_xact, they don't
expose the nodeid atm, I personally am not big fan of the "xact" but it
seems more consistent with existing naming
  - documented pg_resetxlog changes and make all the pg_resetxlog
options alphabetically ordered
  - committs is not used anymore, it's commit_ts (and CommitTs in
camelcase), I think it's not really good idea to spell the timestamp
everywhere as some interface then get 30+ chars long names...
  - added WAL logging of the track_commit_timestamp GUC
  - added alternative expected output of the regression test so that it
works with make installcheck when track_commit_timestamp is on
  - added C interface to set default nodeid for current backend
  - several minor comment and naming adjustments mostly suggested by Michael


--
  Petr Jelinek                  http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: using custom scan nodes to prototype parallel sequential scan
Next
From: Ants Aasma
Date:
Subject: Re: Failback to old master