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 по дате отправления: