pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore
12+ messages / 5 participants
[nested] [flat]
* BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore
@ 2014-07-24 19:11 s.zuban@gmail.com
0 siblings, 1 reply; 12+ messages in thread
From: s.zuban@gmail.com @ 2014-07-24 19:11 UTC (permalink / raw)
To: pgsql-bugs
The following bug has been logged on the website:
Bug reference: 11032
Logged by: Sergiy Zuban
Email address: s.zuban@gmail.com
PostgreSQL version: 9.3.5
Operating system: Linux
Description:
After upgrade from 9.3.4 to 9.3.5 pg_last_xact_replay_timestamp() returns
outdated timestamp.
It stopped working properly after commit
d19bd29f07aef9e508ff047d128a4046cc8bc1e2
COMMIT PREPARED should update transaction timestamp, but it doesn't seem to
happen.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore
@ 2014-07-24 21:46 Tom Lane <tgl@sss.pgh.pa.us>
parent: s.zuban@gmail.com
0 siblings, 2 replies; 12+ messages in thread
From: Tom Lane @ 2014-07-24 21:46 UTC (permalink / raw)
To: s.zuban@gmail.com; +Cc: pgsql-bugs
s.zuban@gmail.com writes:
> After upgrade from 9.3.4 to 9.3.5 pg_last_xact_replay_timestamp() returns
> outdated timestamp.
> It stopped working properly after commit
> d19bd29f07aef9e508ff047d128a4046cc8bc1e2
Really?
It looks to me like this never worked: the code around recoveryStopsHere
has never paid any attention to COMMIT_PREPARED (or ABORT_PREPARED).
Certainly that patch had zip to do with the replay-timestamp behavior.
If you think it worked before, I'd like to see what your test case was.
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore
@ 2014-07-24 21:57 Andres Freund <andres@2ndquadrant.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 12+ messages in thread
From: Andres Freund @ 2014-07-24 21:57 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: s.zuban@gmail.com; pgsql-bugs
On 2014-07-24 17:46:13 -0400, Tom Lane wrote:
> s.zuban@gmail.com writes:
> > After upgrade from 9.3.4 to 9.3.5 pg_last_xact_replay_timestamp() returns
> > outdated timestamp.
>
> > It stopped working properly after commit
> > d19bd29f07aef9e508ff047d128a4046cc8bc1e2
>
> Really?
>
> It looks to me like this never worked: the code around recoveryStopsHere
> has never paid any attention to COMMIT_PREPARED (or ABORT_PREPARED).
> Certainly that patch had zip to do with the replay-timestamp behavior.
>
> If you think it worked before, I'd like to see what your test case was.
I wonder if this is possibly influenced by
bb38fb0d43c8d7ff54072bfd8bd63154e536b384. IIRC before it committing a
prepared xact caused a plain commit record for the xid doing the COMMIT
PREPARED.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore
@ 2014-07-24 22:32 Tom Lane <tgl@sss.pgh.pa.us>
parent: Andres Freund <andres@2ndquadrant.com>
0 siblings, 1 reply; 12+ messages in thread
From: Tom Lane @ 2014-07-24 22:32 UTC (permalink / raw)
To: Andres Freund <andres@2ndquadrant.com>; +Cc: s.zuban@gmail.com, pgsql-bugs@postgresql.org, Heikki Linnakangas <hlinnakangas@vmware.com>
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-07-24 17:46:13 -0400, Tom Lane wrote:
>> It looks to me like this never worked: the code around recoveryStopsHere
>> has never paid any attention to COMMIT_PREPARED (or ABORT_PREPARED).
> I wonder if this is possibly influenced by
> bb38fb0d43c8d7ff54072bfd8bd63154e536b384. IIRC before it committing a
> prepared xact caused a plain commit record for the xid doing the COMMIT
> PREPARED.
Hm, I see nothing in that commit that looks like it would've changed
what gets written to WAL (and if it did, we have a serious minor version
compatibility issue). OTOH, if it did, that would explain the
complaint of a behavioral change since the last minor releases.
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore
@ 2014-07-24 22:34 Andres Freund <andres@2ndquadrant.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 12+ messages in thread
From: Andres Freund @ 2014-07-24 22:34 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: s.zuban@gmail.com, pgsql-bugs@postgresql.org, Heikki Linnakangas <hlinnakangas@vmware.com>
On 2014-07-24 18:32:09 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-07-24 17:46:13 -0400, Tom Lane wrote:
> >> It looks to me like this never worked: the code around recoveryStopsHere
> >> has never paid any attention to COMMIT_PREPARED (or ABORT_PREPARED).
>
> > I wonder if this is possibly influenced by
> > bb38fb0d43c8d7ff54072bfd8bd63154e536b384. IIRC before it committing a
> > prepared xact caused a plain commit record for the xid doing the COMMIT
> > PREPARED.
>
> Hm, I see nothing in that commit that looks like it would've changed
> what gets written to WAL (and if it did, we have a serious minor version
> compatibility issue). OTOH, if it did, that would explain the
> complaint of a behavioral change since the last minor releases.
Afaics before the commit a LockGXact() did a GetTopTransactionId(),
afterwards it doesn't anymore. That'd fit, right?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore
@ 2014-07-24 22:50 Tom Lane <tgl@sss.pgh.pa.us>
parent: Andres Freund <andres@2ndquadrant.com>
0 siblings, 1 reply; 12+ messages in thread
From: Tom Lane @ 2014-07-24 22:50 UTC (permalink / raw)
To: Andres Freund <andres@2ndquadrant.com>; +Cc: s.zuban@gmail.com, pgsql-bugs@postgresql.org, Heikki Linnakangas <hlinnakangas@vmware.com>
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore
@ 2014-07-25 15:21 Sergiy Zuban <s.zuban@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 12+ messages in thread
From: Sergiy Zuban @ 2014-07-25 15:21 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-bugs
Prior to this change probably it was working not properly in 100% of cases
(timestamp was updated even if prepared transaction wasn't committed yet?),
but still it was a good way to check replication delay and it worked. Now
pg_last_xact_replay_timestamp() is useless for such purpose and I hope you
can fix this in next minor release.
--
Sergiy Zuban
On Thu, Jul 24, 2014 at 4:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> s.zuban@gmail.com writes:
> > After upgrade from 9.3.4 to 9.3.5 pg_last_xact_replay_timestamp() returns
> > outdated timestamp.
>
> > It stopped working properly after commit
> > d19bd29f07aef9e508ff047d128a4046cc8bc1e2
>
> Really?
>
> It looks to me like this never worked: the code around recoveryStopsHere
> has never paid any attention to COMMIT_PREPARED (or ABORT_PREPARED).
> Certainly that patch had zip to do with the replay-timestamp behavior.
>
> If you think it worked before, I'd like to see what your test case was.
>
> regards, tom lane
>
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore
@ 2014-07-28 10:05 Heikki Linnakangas <hlinnakangas@vmware.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 12+ messages in thread
From: Heikki Linnakangas @ 2014-07-28 10:05 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Andres Freund <andres@2ndquadrant.com>; +Cc: s.zuban@gmail.com; pgsql-bugs
On 07/25/2014 01:50 AM, Tom Lane wrote:
> 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.
Yep. The extra commit record masked the issue that getRecordTimestamp()
ignores commit/abort prepared records.
> 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.
Hmm. I've always considered it just a quirk that we didn't bother to fix
when two-phase commit was implemented, because it would've required more
invasive code changes. But the code has since moved on - not all
transactions are assigned an XID anymore - and now it was
straightforward to fix that quirk.
It wouldn't surprise me much though, if we find more little things like
this that were previously masked by the extra commit record:
At a quick glance, the recovery_min_apply_delay code in xlog.c seems to
be oblivious of prepared transactions. Now that we no longer write the
normal COMMIT record after a COMMIT_PREPARED record, that's become
worse, but it was always wrong. The COMMIT_PREPARED record would always
be applied immediately, regardless of recovery_min_apply_delay, although
we would then pause at the commit record that follows. The
recovery_target_xid handling also ignores prepared transactions.
> 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.
RecordTransactionCommitPrepared calls XLogFlush() and
SyncRepWaitForLSN(), so those particular things are covered.
We probably should set XLogRecord->xl_xid in COMMIT_/ABORT_PREPARED
records though. It seems weird not to, and it would simplify code that
interprets those records. But I don't think we should back-patch that.
> 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.
Time-of-commit makes much more sense to me. The transaction doesn't
appear as committed to other transactions until it's committed,
regardless of when it prepared.
It surprises me that there is no timestamp at all in the prepare-record
though. That could be very useful information, if you wanted to monitor
the delay between prepare and commit, for example. But that's another issue.
I propose the attached (untested) patch that fixes the issues mentioned
this far. I'll set up streaming replication and test
recovery_target_xid, recovery_min_apply_delay, and
pg_last_xact_replay_timestamp() with the patch, and barring
objections/bugs, commit and backpatch. For master branch, I'll
investigate how hacky it would be to set XLogRecord->xl_xid to the XID
of the prepared transaction.
- Heikki
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Attachments:
fix-commit-abort-prepared-oversights-1.patch (text/x-diff, 5.5K) download
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 93f3ca2..2bf49a8 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -5457,11 +5457,21 @@ getRecordTimestamp(XLogRecord *record, TimestampTz *recordXtime)
*recordXtime = ((xl_xact_commit *) XLogRecGetData(record))->xact_time;
return true;
}
+ if (record->xl_rmid == RM_XACT_ID && record_info == XLOG_XACT_COMMIT_PREPARED)
+ {
+ *recordXtime = ((xl_xact_commit_prepared *) XLogRecGetData(record))->crec.xact_time;
+ return true;
+ }
if (record->xl_rmid == RM_XACT_ID && record_info == XLOG_XACT_ABORT)
{
*recordXtime = ((xl_xact_abort *) XLogRecGetData(record))->xact_time;
return true;
}
+ if (record->xl_rmid == RM_XACT_ID && record_info == XLOG_XACT_ABORT_PREPARED)
+ {
+ *recordXtime = ((xl_xact_abort_prepared *) XLogRecGetData(record))->arec.xact_time;
+ return true;
+ }
return false;
}
@@ -5480,6 +5490,7 @@ recoveryStopsBefore(XLogRecord *record)
uint8 record_info;
bool isCommit;
TimestampTz recordXtime = 0;
+ TransactionId recordXid;
/* Check if we should stop as soon as reaching consistency */
if (recoveryTarget == RECOVERY_TARGET_IMMEDIATE && reachedConsistency)
@@ -5498,10 +5509,27 @@ recoveryStopsBefore(XLogRecord *record)
if (record->xl_rmid != RM_XACT_ID)
return false;
record_info = record->xl_info & ~XLR_INFO_MASK;
+
if (record_info == XLOG_XACT_COMMIT_COMPACT || record_info == XLOG_XACT_COMMIT)
+ {
+ isCommit = true;
+ recordXid = record->xl_xid;
+ }
+ if (record_info == XLOG_XACT_COMMIT_PREPARED)
+ {
isCommit = true;
+ recordXid = ((xl_xact_commit_prepared *) XLogRecGetData(record))->xid;
+ }
else if (record_info == XLOG_XACT_ABORT)
+ {
+ isCommit = false;
+ recordXid = record->xl_xid;
+ }
+ else if (record_info == XLOG_XACT_ABORT_PREPARED)
+ {
isCommit = false;
+ recordXid = ((xl_xact_abort_prepared *) XLogRecGetData(record))->xid;
+ }
else
return false;
@@ -5516,7 +5544,7 @@ recoveryStopsBefore(XLogRecord *record)
* they complete. A higher numbered xid will complete before you about
* 50% of the time...
*/
- stopsHere = (record->xl_xid == recoveryTargetXid);
+ stopsHere = (recordXid == recoveryTargetXid);
}
if (recoveryTarget == RECOVERY_TARGET_TIME &&
@@ -5536,7 +5564,7 @@ recoveryStopsBefore(XLogRecord *record)
if (stopsHere)
{
recoveryStopAfter = false;
- recoveryStopXid = record->xl_xid;
+ recoveryStopXid = recordXid;
recoveryStopTime = recordXtime;
recoveryStopName[0] = '\0';
@@ -5602,12 +5630,24 @@ recoveryStopsAfter(XLogRecord *record)
if (record->xl_rmid == RM_XACT_ID &&
(record_info == XLOG_XACT_COMMIT_COMPACT ||
record_info == XLOG_XACT_COMMIT ||
- record_info == XLOG_XACT_ABORT))
+ record_info == XLOG_XACT_COMMIT_PREPARED ||
+ record_info == XLOG_XACT_ABORT ||
+ record_info == XLOG_XACT_ABORT_PREPARED))
{
+ TransactionId recordXid;
+
/* Update the last applied transaction timestamp */
if (getRecordTimestamp(record, &recordXtime))
SetLatestXTime(recordXtime);
+ /* Extract the XID of the committed/aborted transaction */
+ if (record_info == XLOG_XACT_COMMIT_PREPARED)
+ recordXid = ((xl_xact_commit_prepared *) XLogRecGetData(record))->xid;
+ else if (record_info == XLOG_XACT_ABORT_PREPARED)
+ recordXid = ((xl_xact_abort_prepared *) XLogRecGetData(record))->xid;
+ else
+ recordXid = record->xl_xid;
+
/*
* There can be only one transaction end record with this exact
* transactionid
@@ -5618,21 +5658,24 @@ recoveryStopsAfter(XLogRecord *record)
* 50% of the time...
*/
if (recoveryTarget == RECOVERY_TARGET_XID && recoveryTargetInclusive &&
- record->xl_xid == recoveryTargetXid)
+ recordXid == recoveryTargetXid)
{
recoveryStopAfter = true;
- recoveryStopXid = record->xl_xid;
+ recoveryStopXid = recordXid;
recoveryStopTime = recordXtime;
recoveryStopName[0] = '\0';
- if (record_info == XLOG_XACT_COMMIT_COMPACT || record_info == XLOG_XACT_COMMIT)
+ if (record_info == XLOG_XACT_COMMIT_COMPACT ||
+ record_info == XLOG_XACT_COMMIT ||
+ record_info == XLOG_XACT_COMMIT_PREPARED)
{
ereport(LOG,
(errmsg("recovery stopping after commit of transaction %u, time %s",
recoveryStopXid,
timestamptz_to_str(recoveryStopTime))));
}
- else if (record_info == XLOG_XACT_ABORT)
+ else if (record_info == XLOG_XACT_ABORT ||
+ record_info == XLOG_XACT_ABORT_PREPARED)
{
ereport(LOG,
(errmsg("recovery stopping after abort of transaction %u, time %s",
@@ -5745,7 +5788,8 @@ recoveryApplyDelay(XLogRecord *record)
record_info = record->xl_info & ~XLR_INFO_MASK;
if (!(record->xl_rmid == RM_XACT_ID &&
(record_info == XLOG_XACT_COMMIT_COMPACT ||
- record_info == XLOG_XACT_COMMIT)))
+ record_info == XLOG_XACT_COMMIT ||
+ record_info == XLOG_XACT_COMMIT_PREPARED)))
return false;
if (!getRecordTimestamp(record, &xtime))
diff --git a/src/include/access/xact.h b/src/include/access/xact.h
index 10ee943..2168dc3 100644
--- a/src/include/access/xact.h
+++ b/src/include/access/xact.h
@@ -180,8 +180,7 @@ typedef struct xl_xact_abort
/*
* 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.
+ * --- the XID in the record header will be invalid.
*/
typedef struct xl_xact_commit_prepared
* Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore
@ 2014-07-28 14:17 Andres Freund <andres@2ndquadrant.com>
parent: Heikki Linnakangas <hlinnakangas@vmware.com>
1 sibling, 1 reply; 12+ messages in thread
From: Andres Freund @ 2014-07-28 14:17 UTC (permalink / raw)
To: Heikki Linnakangas <hlinnakangas@vmware.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; s.zuban@gmail.com; pgsql-bugs
On 2014-07-28 13:05:13 +0300, Heikki Linnakangas wrote:
> We probably should set XLogRecord->xl_xid in COMMIT_/ABORT_PREPARED records
> though. It seems weird not to, and it would simplify code that interprets
> those records. But I don't think we should back-patch that.
I doubt that'd be a net improvement - wouldn't that just make the life
of anything tracking xid liveliness a bit more complicated?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore
@ 2014-07-28 17:58 Heikki Linnakangas <hlinnakangas@vmware.com>
parent: Andres Freund <andres@2ndquadrant.com>
0 siblings, 1 reply; 12+ messages in thread
From: Heikki Linnakangas @ 2014-07-28 17:58 UTC (permalink / raw)
To: Andres Freund <andres@2ndquadrant.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; s.zuban@gmail.com; pgsql-bugs
On 07/28/2014 05:17 PM, Andres Freund wrote:
> On 2014-07-28 13:05:13 +0300, Heikki Linnakangas wrote:
>> We probably should set XLogRecord->xl_xid in COMMIT_/ABORT_PREPARED records
>> though. It seems weird not to, and it would simplify code that interprets
>> those records. But I don't think we should back-patch that.
>
> I doubt that'd be a net improvement - wouldn't that just make the life
> of anything tracking xid liveliness a bit more complicated?
How so?
- Heikki
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore
@ 2014-07-28 18:07 Andres Freund <andres@2ndquadrant.com>
parent: Heikki Linnakangas <hlinnakangas@vmware.com>
0 siblings, 0 replies; 12+ messages in thread
From: Andres Freund @ 2014-07-28 18:07 UTC (permalink / raw)
To: Heikki Linnakangas <hlinnakangas@vmware.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; s.zuban@gmail.com; pgsql-bugs
On 2014-07-28 20:58:25 +0300, Heikki Linnakangas wrote:
> On 07/28/2014 05:17 PM, Andres Freund wrote:
> >On 2014-07-28 13:05:13 +0300, Heikki Linnakangas wrote:
> >>We probably should set XLogRecord->xl_xid in COMMIT_/ABORT_PREPARED records
> >>though. It seems weird not to, and it would simplify code that interprets
> >>those records. But I don't think we should back-patch that.
> >
> >I doubt that'd be a net improvement - wouldn't that just make the life
> >of anything tracking xid liveliness a bit more complicated?
>
> How so?
Nothing super concrete. Doesn't feel entirely right ;): It's imo
confusing if records for the same xid are possibly created by two
different backends and that there suddenly can be an additional WAL
record referring to the xid after it's been prepared.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore
@ 2014-07-29 09:03 Heikki Linnakangas <hlinnakangas@vmware.com>
parent: Heikki Linnakangas <hlinnakangas@vmware.com>
1 sibling, 0 replies; 12+ messages in thread
From: Heikki Linnakangas @ 2014-07-29 09:03 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Andres Freund <andres@2ndquadrant.com>; +Cc: s.zuban@gmail.com; pgsql-bugs
On 07/28/2014 01:05 PM, Heikki Linnakangas wrote:
> I propose the attached (untested) patch that fixes the issues mentioned
> this far.
Committed and backpatched.
- Heikki
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
^ permalink raw reply [nested|flat] 12+ messages in thread
end of thread, other threads:[~2014-07-29 09:03 UTC | newest]
Thread overview: 12+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2014-07-24 19:11 BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore s.zuban@gmail.com
2014-07-24 21:46 ` Tom Lane <tgl@sss.pgh.pa.us>
2014-07-24 21:57 ` Andres Freund <andres@2ndquadrant.com>
2014-07-24 22:32 ` Tom Lane <tgl@sss.pgh.pa.us>
2014-07-24 22:34 ` Andres Freund <andres@2ndquadrant.com>
2014-07-24 22:50 ` Tom Lane <tgl@sss.pgh.pa.us>
2014-07-28 10:05 ` Heikki Linnakangas <hlinnakangas@vmware.com>
2014-07-28 14:17 ` Andres Freund <andres@2ndquadrant.com>
2014-07-28 17:58 ` Heikki Linnakangas <hlinnakangas@vmware.com>
2014-07-28 18:07 ` Andres Freund <andres@2ndquadrant.com>
2014-07-29 09:03 ` Heikki Linnakangas <hlinnakangas@vmware.com>
2014-07-25 15:21 ` Sergiy Zuban <s.zuban@gmail.com>
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