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
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>
Comments: In-reply-to Andres Freund <andres@2ndquadrant.com>
 message dated "Fri, 25 Jul 2014 00:34:59 +0200"
Date: Thu, 24 Jul 2014 18:50:32 -0400
Message-ID: <21620.1406242232@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org

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