A little improvementof ApplyLauncherMain loop code
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t37189psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 05:39 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t37189_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t37189_1 && git checkout t37189_1Patchset v1 (message #1) is on t37189_1
Hi,
When reading the logical replication code, I found that the following
part could be improved a bit. In the foreach, LWLockAcquire and
logicalrep_worker_find are called for each loop, but they are needed
only when sub->enabled is true.
846 /* Start the missing workers for enabled subscriptions. */
847 foreach(lc, sublist)
848 {
849 Subscription *sub = (Subscription *) lfirst(lc);
850 LogicalRepWorker *w;
851
852 LWLockAcquire(LogicalRepWorkerLock, LW_SHARED);
853 w = logicalrep_worker_find(sub->oid, InvalidOid, false);
854 LWLockRelease(LogicalRepWorkerLock);
855
856 if (sub->enabled && w == NULL)
857 {
858 last_start_time = now;
859 wait_time = wal_retrieve_retry_interval;
860
861 logicalrep_worker_launch(sub->dbid, sub->oid, sub->name,
862 sub->owner, InvalidOid);
863 }
864 }
We can fix this to call them only when there are needed, but I'm not sure
whether these call are expensive enough to fix. Is it worth to fix?
A patch attached.
Regards,
--
Yugo Nagata <nagata@sraoss.co.jp>
On 8/1/17 02:28, Yugo Nagata wrote:
When reading the logical replication code, I found that the following
part could be improved a bit. In the foreach, LWLockAcquire and
logicalrep_worker_find are called for each loop, but they are needed
only when sub->enabled is true.
Fixed, thanks!
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, 15 Aug 2017 15:17:06 -0400
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
On 8/1/17 02:28, Yugo Nagata wrote:
When reading the logical replication code, I found that the following
part could be improved a bit. In the foreach, LWLockAcquire and
logicalrep_worker_find are called for each loop, but they are needed
only when sub->enabled is true.Fixed, thanks!
Thanks, too!
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Yugo Nagata <nagata@sraoss.co.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers