On 27/11/16 23:42, Erik Rijkers wrote:
> 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)
>
I found the reason. It's not just vacuum (which was what confused me)
it's when the publishing side sends the info about relation again (which
happens when there was cache invalidation on the relation and then new
data were written) and I did free one pointer that I never set. I'll
send fixed patch tomorrow.
Thanks!
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services