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 |
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 |
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? |