Message-ID: <5374F44B.1060003@vmware.com>
Date: Thu, 15 May 2014 20:07:23 +0300
From: Heikki Linnakangas <hlinnakangas@vmware.com>
Organization: VMware
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Icedove/24.4.0
MIME-Version: 1.0
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
 Andres Freund <andres@2ndquadrant.com>
Subject: Re: Logical replication woes
References: <5374F1FF.9000902@vmware.com>
In-Reply-To: <5374F1FF.9000902@vmware.com>
Content-Type: multipart/mixed; boundary="------------040106080505020608010405"
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

This is a multi-part message in MIME format.
--------------040106080505020608010405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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';

pg_recvlogical prints nothing.

- Heikki

--------------040106080505020608010405
Content-Type: text/x-diff;
 name="fix-commit-prepared-decoding-1.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="fix-commit-prepared-decoding-1.patch"

diff --git a/src/backend/replication/logical/decode.c b/src/backend/replication/logical/decode.c
index d6499d5..cc73652 100644
--- a/src/backend/replication/logical/decode.c
+++ b/src/backend/replication/logical/decode.c
@@ -225,7 +225,7 @@ DecodeXactOp(LogicalDecodingContext *ctx, XLogRecordBuffer *buf)
 				subxacts = (TransactionId *) &(xlrec->xnodes[xlrec->nrels]);
 				invals = (SharedInvalidationMessage *) &(subxacts[xlrec->nsubxacts]);
 
-				DecodeCommit(ctx, buf, prec->xl_xid, xlrec->dbId,
+				DecodeCommit(ctx, buf, prec->xid, xlrec->dbId,
 							 xlrec->xact_time,
 							 xlrec->nsubxacts, subxacts,
 							 xlrec->nmsgs, invals);

--------------040106080505020608010405
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--------------040106080505020608010405--