On 2014-05-15 20:07:23 +0300, Heikki Linnakangas wrote:
> 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';
How very wierd. The reason for this is that
RecordTransactionCommitPrepared() forgets to fill a couple of fields in
xl_xact_commit. Any reason dbId/tsId aren't filled? They aren't strictly
needed because afaics they're only looked at for relcache invalidations
which prepared xacts don't support, but still?
That also explains why decoding for prepared xacts (besides the "typo"
you found) didn't work anymore - the filtering at commit was added
pretty late...
Attached patch fixes things, but I want to add some regression tests
before commit.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services