Re: tracking commit timestamps - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: tracking commit timestamps
Date
Msg-id 546E767E.50009@2ndquadrant.com
Whole thread Raw
In response to Re: tracking commit timestamps  (Steve Singer <steve@ssinger.info>)
Responses Re: tracking commit timestamps
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: 9.5: Better memory accounting, towards memory-bounded HashAgg
Next
From: Tom Lane
Date:
Subject: Re: [v9.5] Custom Plan API