Re: Logical Replication WIP

On 27/11/16 23:54, Petr Jelinek wrote:
> 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:
>>>> 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!
>

Okay, so here it is, I also included your doc fix, added test for
REPLICA IDENTITY FULL (which also tests this issue as side effect) and
fixed one relcache leak.

I also rebased it against current master as there was some conflict in
the bgworker.c.

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