Re: [HACKERS] tablesync patch broke the assumption that logical repdepends on?

Поиск
Список
Период
Сортировка
От Steve Singer
Тема Re: [HACKERS] tablesync patch broke the assumption that logical repdepends on?
Дата
Msg-id 58F3C586.9050501@ssinger.info
обсуждение исходный текст
Ответ на [HACKERS] tablesync patch broke the assumption that logical rep depends on?  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: [HACKERS] tablesync patch broke the assumption that logical repdepends on?
Список pgsql-hackers
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.





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c
Следующее
От: Petr Jelinek
Дата:
Сообщение: Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c