Questions about logicalrep_worker_launch() - Mailing list pgsql-hackers

From Fujii Masao
Subject Questions about logicalrep_worker_launch()
Date
Msg-id d9e208a0-1bdf-42e3-b6c6-49bca1904060@oss.nttdata.com
Whole thread Raw
Responses Re: Questions about logicalrep_worker_launch()
List 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

pgsql-hackers by date:

Previous
From: Nikita Malakhov
Date:
Subject: Re: Introduce some randomness to autovacuum
Next
From: Xuneng Zhou
Date:
Subject: Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache