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
Re: tracking commit timestamps |
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: