From: | Petr Jelinek <petr(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Steve Singer <steve(at)ssinger(dot)info>, Andres Freund <andres(at)2ndquadrant(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Anssi Kääriäinen <anssi(dot)kaariainen(at)thl(dot)fi>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Jaime Casanova <jaime(at)2ndquadrant(dot)com> |
Subject: | Re: tracking commit timestamps |
Date: | 2014-11-12 13:06:41 |
Message-ID: | 54635B61.4050106@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers Postg토토 베이SQL : Postg토토 베이SQL 메일 링리스트 : 2014-11-12 이후 PGSQL www |
On 10/11/14 14:53, Robert Haas wrote:
> On Mon, Nov 10, 2014 at 8:39 AM, Petr Jelinek <petr(at)2ndquadrant(dot)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 | Content-Type | Size |
---|---|---|
committs-v8.patch | text/x-diff | 69.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Ants Aasma | 2014-11-12 13:28:53 | Re: Failback to old master |
Previous Message | Robert Haas | 2014-11-12 12:49:37 | Re: using custom scan nodes to prototype parallel sequential scan |
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2014-11-12 22:56:36 | Re: tracking commit timestamps |
Previous Message | Magnus Hagander | 2014-11-12 08:03:08 | Re: git.postgresql.org not finding a commit |