From: Andres Freund <andres@2ndquadrant.com>
To: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: Logical replication woes
Date: Thu, 15 May 2014 19:11:24 +0200
Message-ID: <20140515171124.GH23662@alap3.anarazel.de> (raw)
In-Reply-To: <5374F44B.1060003@vmware.com>
References: <5374F1FF.9000902@vmware.com>
<5374F44B.1060003@vmware.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: andres@2ndquadrant.com, hlinnakangas@vmware.com
Subject: Re: Logical replication woes
In-Reply-To: <20140515171124.GH23662@alap3.anarazel.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox