On 2016-11-27 19:57, Petr Jelinek wrote:
On 22/11/16 18:42, Erik Rijkers wrote:
On 2016-11-20 19:02, Petr Jelinek wrote:
0001-Add-support-for-TE...cation-slots-v8.patch.gz (~8 KB)
0002-Refactor-libpqwalreceiver-v8.patch.gz (~9 KB)
0003-Add-PUBLICATION-catalogs-and-DDL-v8.patch.gz (~30 KB)
0004-Add-SUBSCRIPTION-catalog-and-DDL-v8.patch.gz (~27 KB)
0005-Define-logical-rep...output-plugi-v8.patch.gz (~13 KB)
0006-Add-logical-replication-workers-v8.patch.gz (~43 KB)
0007-Add-separate-synch...for-logical--v8.patch.gz (~2 KB)
Apply, make, make check, install OK.
A crash of the subscriber can be forced by running vacuum <published
table> on the publisher.
- publisher
create table if not exists testt( id integer primary key, c text );
create publication pub1 for table testt;
- subscriber
create table if not exists testt( id integer primary key, c text );
create subscription sub1 connection 'dbname=testdb port=6444'
publication pub1 with (disabled);
alter subscription sub1 enable;
- publisher
vacuum testt;
now data change on the published table, (perhaps also a select on the
subscriber-side data) leads to:
- subscriber log:
TRAP: FailedAssertion("!(pointer != ((void *)0))", File: "mcxt.c",
Line:
1001)
I very much doubt this is problem of vacuum as it does not send
anything
to subscriber. Is there anything else you did on those servers?
It is not the vacuum that triggers the crash but the data change (insert
or delete, on the publisher) /after/ that vacuum.
Just now, I compiled 2 instances from master and such a crash (after
vacuum + delete) seems reliable here.
(If you can't duplicate such a crash let me know; then I'll dig out more
precise set-up detail)
(by the way, the logical replication between the two instances works
well otherwise)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
