From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@2ndquadrant.com>
Cc: s.zuban@gmail.com, pgsql-bugs@postgresql.org, Heikki Linnakangas <hlinnakangas@vmware.com>
Subject: Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore
Date: Thu, 24 Jul 2014 18:50:32 -0400
Message-ID: <21620.1406242232@sss.pgh.pa.us> (raw)
In-Reply-To: <20140724223459.GI16857@alap3.anarazel.de>
References: <20140724191127.32089.82261@wrigleys.postgresql.org>
<20429.1406238373@sss.pgh.pa.us>
<20140724215743.GG16857@alap3.anarazel.de>
<21266.1406241129@sss.pgh.pa.us>
<20140724223459.GI16857@alap3.anarazel.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>
Andres Freund <andres@2ndquadrant.com> writes:
> Afaics before the commit a LockGXact() did a GetTopTransactionId(),
> afterwards it doesn't anymore. That'd fit, right?
Ah, I think you've got it. Now I'm worried. I have a very vague
recollection that that behavior (forcing our own COMMIT to be written
after a COMMIT PREPARED) was intentional. I don't recall exactly
why though.
xact.h points out
/*
* COMMIT_PREPARED and ABORT_PREPARED are identical to COMMIT/ABORT records
* except that we have to store the XID of the prepared transaction explicitly
* --- the XID in the record header will be for the transaction doing the
* COMMIT PREPARED or ABORT PREPARED command.
*/
and what this change means is that there isn't actually any valid XID in
the record header, which at least means that comment needs an update.
But I'm concerned about the knock-on aspects of that. In particular
I wonder if we were expecting commit of the surrounding transaction to
result in a WAL flush or anything like that. The proposal you made
recently to not sync non-XID-assigning WAL records would affect this.
As far as the timestamp aspects go, I wonder if we were thinking that
commit/abort prepared might contain stale timestamps by design. They
don't --- in the current coding, the timestamp is the time of creating the
WAL record, not of the prepare --- but it's not that hard to imagine that
time-of-prepare might have been the original intent.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@2ndquadrant.com, hlinnakangas@vmware.com
Subject: Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore
In-Reply-To: <21620.1406242232@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox