From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Questions about logicalrep_worker_launch() |
Date: | 2025-04-25 16:09:58 |
Message-ID: | d9e208a0-1bdf-42e3-b6c6-49bca1904060@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
While reading the code of logicalrep_worker_launch(), I had two questions:
(1)
When the sync worker limit per subscription is reached, logicalrep_worker_launch()
runs garbage collection to try to free up slots before checking the limit again.
That makes sense.
But should we do the same when the parallel apply worker limit is reached?
Currently, if we've hit the parallel apply worker limit but not the sync worker limit
and we find an unused worker slot, garbage collection doesn't run. Would it
make sense to also run garbage collection in that case?
(2)
If garbage collection removes at least one worker, logicalrep_worker_launch()
scans all worker slots again to look for a free one. But since we know at least one
slot was freed, this retry might be unnecessary. We could just reuse the freed
slot directly. Is that correct?
The attached patch addresses both points. Since logicalrep_worker_launch()
isn't a performance-critical path, this might not be a high-priority change.
But if my understanding is correct, I'm a bit tempted to apply it as a refactoring.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Refactor-logicalrep_worker_launch.patch | text/plain | 4.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Xuneng Zhou | 2025-04-25 16:17:31 | Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache |
Previous Message | Nikita Malakhov | 2025-04-25 15:16:11 | Re: Introduce some randomness to autovacuum |