Hi, On 2014-05-15 20:07:23 +0300, Heikki Linnakangas wrote: > On 05/15/2014 07:57 PM, Heikki Linnakangas wrote: > >Spotted while testing pg_recvlogical: > > > >1. Set up pg_recvlogical to receive: > > > >./pg_recvlogical -S fooslot -d postgres --create > >./pg_recvlogical -S fooslot -d postgres --start -f - > > > >2. In another terminal, with psql: > > > >create table foo (id int4); > >begin; > > insert into foo values (4); > > alter table foo alter column id type text; > >prepare transaction 'foo'; > >commit prepared 'foo'; > >insert into foo values (1); > > > >3. With current HEAD, after commit > >bb38fb0d43c8d7ff54072bfd8bd63154e536b384, this produces an assertion > >failure: > > > >TRAP: FailedAssertion("!(((xid) != ((TransactionId) 0)))", File: > >"reorderbuffer.c", Line: 508) > > > >I believe that's we no longer assign another XID to the transaction that > >does the COMMIT PREPARED. Previously, an extra XID, in addition to the > >XID of the prepared transaction, was assigned for use in locking the > >global transaction entry in shared memory, but that's no longer required. > > > >However, even with that patch reverted, it doesn't work correctly: > > > >ERROR: could not map filenode "base/12142/16390" to relation OID > >LOG: starting logical decoding for slot fooslot > >DETAIL: streaming transactions committing after 0/16D1670, reading WAL > >from 0/16BC470 > > Ok, so the immediate cause was quick to find: when decoding a > commit-prepared WAL record, we have to use the XID from the record content > (patch attached). The XID in the record header is the XID of the transaction > doing the COMMIT PREPARED, which is always 0 after patch > bb38fb0d43c8d7ff54072bfd8bd63154e536b384 which causes the assertion. But it > was always wrong. After fixing, it no longer asserts or gives the above > "could not map filenode" error. > > However, it still doesn't seem right. When I do the above as a regular > transaction, ie: > > begin; insert into foo values (6); alter table foo alter column id type > text; commit; > > pg_recvlogical prints this: > > BEGIN 708 > table public.foo: INSERT: id[text]:'6' > COMMIT 708 > > But if I do it as a prepared transaction: > > begin; insert into foo values (7); alter table foo alter column id type > text; prepare transaction 'foo'; commit prepared 'foo';
Looking into it. I at some point dropped the prepared xact tests and that was obviously a mistake. Will re-add them and fix. Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers