Re: tablesync patch broke the assumption that logical rep depends on?

On 16/04/17 21:27, Steve Singer wrote:
> On 04/10/2017 01:28 PM, Fujii Masao wrote:
>> Hi,
>>
>> src/backend/replication/logical/launcher.c
>> * Worker started and attached to our shmem. This check is safe
>> * because only launcher ever starts the workers, so nobody
>> can steal
>> * the worker slot.
>>
>> The tablesync patch enabled even worker to start another worker.
>> So the above assumption is not valid for now.
>>
>> This issue seems to cause the corner case where the launcher picks up
>> the same worker slot that previously-started worker has already picked
>> up to start another worker.
>>
>> Regards,
>>
>
> I'm not sure if what I am seeing is related to this or another issue.
>
> If I create a subscription for a publication that doesn't exist (yet) I
> see 'publication mypub does not exist" in the subscribers log
>
> If I then create the publication on the publisher the error doesn't go
> away, the worker process keeps spinning with the same error.
>
> If I then drop the subscription and recreate it it works.
>

No that's a result of how logical decoding/slots work. We see catalogs
as what they looked like at the specific point in time. If you create
slot (by creating subscription) it will not see publication that was
created after until decoding on that slot reaches point in time when it
was actually created.

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