Re: tracking commit timestamps

On 21/11/14 00:17, Petr Jelinek wrote:
> 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.
>

And here is v10 which fixes conflicts with Heikki's WAL API changes (no
changes otherwise).


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