From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, s(dot)zuban(at)gmail(dot)com, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore |
Date: | 2014-07-28 18:07:12 |
Message-ID: | 20140728180712.GR17793@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | hiapo | 2014-07-29 02:46:55 | BUG #11078: this query crash on array_agg, but there is no array_agg |
Previous Message | Heikki Linnakangas | 2014-07-28 17:58:25 | Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore |