Questions about logicalrep_worker_launch()

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

Responses

Browse pgsql-hackers by date

  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