| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: tablesync patch broke the assumption that logical rep depends on? |
| Date: | 2017-04-13 16:28:25 |
| Message-ID: | 9ce4ce67-429d-6440-ac33-59c799794384@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2017-04-13 16:31:26 | Re: pg_statistic_ext.staenabled might not be the best column name |
| Previous Message | Robert Haas | 2017-04-13 16:25:06 | Re: Undefined psql variables |