From: | Erik Rijkers <er(at)xs4all(dot)nl> |
---|---|
To: | Petr Jelinek <petr(at)2ndquadrant(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Steve Singer <steve(at)ssinger(dot)info>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers-owner(at)postgresql(dot)org |
Subject: | Re: Logical Replication WIP |
Date: | 2016-11-27 22:42:47 |
Message-ID: | e9c8ea4079fe1798264f0839d05fcdf7@xs4all.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-11-27 22:45:36 | Re: Autovacuum breakage from a734fd5d1 |
Previous Message | Andres Freund | 2016-11-27 22:02:14 | Re: PATCH: two slab-like memory allocators |