Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore
От | Andres Freund |
---|---|
Тема | Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore |
Дата | |
Msg-id | 20140724223459.GI16857@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: