Re: Logical Replication WIP - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: Logical Replication WIP
Date
Msg-id 98343d79-f2e7-caa5-08bf-4ec18396c113@2ndquadrant.com
Whole thread Raw
In response to Re: Logical Replication WIP  (Erik Rijkers <er@xs4all.nl>)
Responses Re: Logical Replication WIP  (Erik Rijkers <er@xs4all.nl>)
List pgsql-hackers
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)
> 2016-11-22 18:13:13.983 CET 10177 LOG:  worker process: ??)? (PID 10334)
> was terminated by signal 6: Aborted
> 2016-11-22 18:13:13.983 CET 10177 LOG:  terminating any other active
> server processes
> 2016-11-22 18:13:13.983 CET 10338 WARNING:  terminating connection
> because of crash of another server process
> 2016-11-22 18:13:13.983 CET 10338 DETAIL:  The postmaster has commanded
> this server process to roll back the current transaction and exit,
> because another server process exited abnormally and possibly corrupted
> shared memory.
> [...]
> 

Hi, thanks for report.

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?

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Autovacuum breakage from a734fd5d1
Next
From: Artur Zakirov
Date:
Subject: Re: [BUG?] pg_event_trigger_ddl_commands() error with ALTER TEXT SEARCH CONFIGURATION