On 05/15/2014 08:46 PM, Andres Freund wrote:
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?
Seems like an oversight in commit dd428c79, which added the fields to
xl_xact_commit. They are needed. A prepared xact can indeed cause
relcache invalidations, and removal of the init file. For example:
begin; cluster pg_opclass using pg_opclass_oid_index ; prepare
transaction 'foo'; commit prepared 'foo';
Attached patch fixes things, but I want to add some regression tests
before commit.
Looks good to me.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
