Re: Logical Replication WIP

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)