Re: [HACKERS] tablesync patch broke the assumption that logical repdepends on? - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] tablesync patch broke the assumption that logical repdepends on?
Date
Msg-id 9ce4ce67-429d-6440-ac33-59c799794384@2ndquadrant.com
Whole thread Raw
In response to [HACKERS] tablesync patch broke the assumption that logical rep depends on?  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: [HACKERS] tablesync patch broke the assumption that logical repdepends on?  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On 4/10/17 13:28, Fujii Masao wrote:
>          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.

I think what the comment should rather say is that workers are always
started through logicalrep_worker_launch() and worker slots are always
handed out while holding LogicalRepWorkerLock exclusively, so nobody can
steal the worker slot.

Does that make sense?

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Undefined psql variables
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] pg_statistic_ext.staenabled might not be the bestcolumn name