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)