Re: tracking commit timestamps

From: Petr Jelinek <petr(at)2ndquadrant(dot)com>
To: Steve Singer <steve(at)ssinger(dot)info>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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>, 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-20 23:17:18
Message-ID: 546E767E.50009@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-www

On 19/11/14 17:30, Steve Singer wrote:
> On 11/19/2014 08:22 AM, Alvaro Herrera wrote:
>>
>> I think we're overblowing the pg_upgrade issue. Surely we don't need to
>> preserve commit_ts data when upgrading across major versions; and
>> pg_upgrade is perfectly prepared to remove old data when upgrading
>> (actually it just doesn't copy it; consider pg_subtrans or pg_serial,
>> for instance.) If we need to change binary representation in a future
>> major release, we can do so without any trouble.
>>
>
> That sounds reasonable. I am okay with Petr removing the LSN portion
> this patch.
>

I did that then, v9 attached with following changes:
- removed lsn info (obviously)

- the pg_xact_commit_timestamp and pg_last_committed_xact return NULLs
when timestamp data was not found

- made the default nodeid crash safe - this also makes use of the
do_xlog parameter in TransactionTreeSetCommitTsData if nodeid is set,
although that still does not happen without extension actually using the API

- added some more regression tests

- some small comment and docs adjustments based on Michael's last email

I didn't change the pg_last_committed_xact function name and I didn't
make nodeid visible from SQL level interfaces and don't plan to in this
patch as I think it's very premature to do so before we have some C code
using it.

Just to explain once more and hopefully more clearly how the crash
safety/WAL logging is handled since there was some confusion in last review:
We only do WAL logging when nodeid is also logged (when nodeid is not 0)
because the timestamp itself can be read from WAL record of transaction
commit so it's pointless to log another WAL record just to store the
timestamp again.
Extension can either set default nodeid which is then logged
transparently, or can override the default logging mechanism by calling
TransactionTreeSetCommitTsData with whatever data it wants and do_xlog
set to true which will then write the WAL record with this overriding
information.
During WAL replay the commit timestamp is set from transaction commit
record and then if committs WAL record is found it's used to overwrite
the commit timestamp/nodeid for given xid.

Also, there is exactly one record in SLRU for each xid so there is no
point in making the SQL interfaces return multiple results.

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

Attachment Content-Type Size
committs-v9.patch text/x-diff 69.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-11-21 00:10:13 Re: [v9.5] Custom Plan API
Previous Message Andres Freund 2014-11-20 23:03:25 Re: 9.5: Better memory accounting, towards memory-bounded HashAgg

Browse pgsql-www by date

  From Date Subject
Next Message Petr Jelinek 2014-11-21 14:22:34 Re: tracking commit timestamps
Previous Message Joshua D. Drake 2014-11-20 16:51:10 Re: Update website to 9.4rc1?