worker_spi example BGW code GUC tweak
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:t37873psql -h localhost -U postgresBuilt from patchset v1 (message #1), October 23, 2026 at 01:33 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 t37873_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 t37873_1 && git checkout t37873_1Patchset v1 (message #1) is on t37873_1
Would this sample code make an even better teaching example if it
used the existing GUC way to declare that worker_spi.naptime is
in units of seconds?
Or does it not do that for some reason I've overlooked?
-Chap
On Thu, Dec 14, 2017 at 5:41 PM, Chapman Flack <chap@anastigmatix.net> wrote:
Would this sample code make an even better teaching example if it
used the existing GUC way to declare that worker_spi.naptime is
in units of seconds?Or does it not do that for some reason I've overlooked?
Making it use GUC_UNIT_S seems like a good idea to me, but removing
the mention of seconds from the description doesn't seem like a good
idea to me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 12/17/2017 07:32 PM, Robert Haas wrote:
Making it use GUC_UNIT_S seems like a good idea to me, but removing
the mention of seconds from the description doesn't seem like a good
idea to me.
I took for my model a quick survey of existing GUCs that use
GUC_UNIT_(MS|S|MIN) - most of which do not restate the time unit
in the text description. (It's not a shut-out; some do, but only
a handful.)
I think that makes sense, because once the GUC_UNIT_foo is
specified, you get output like:
select current_setting('worker_spi.naptime');
current_setting
-----------------
10s
and, if you set it for, say, 120000ms or 180min, it will be
displayed as 2min or 3h, etc., making 'seconds' in the text
description a little redundant in the best case—when the
current value is most naturally shown with s—and a little
goofy in the other cases, where the value would be displayed
with min, h, or d, and reading the value combined with the text
description makes the snarky little voice in your head go
"nap for 3 hours seconds??".
-Chap
On Sun, Dec 17, 2017 at 8:30 PM, Chapman Flack <chap@anastigmatix.net> wrote:
On 12/17/2017 07:32 PM, Robert Haas wrote:
Making it use GUC_UNIT_S seems like a good idea to me, but removing
the mention of seconds from the description doesn't seem like a good
idea to me.I took for my model a quick survey of existing GUCs that use
GUC_UNIT_(MS|S|MIN) - most of which do not restate the time unit
in the text description. (It's not a shut-out; some do, but only
a handful.)I think that makes sense, because once the GUC_UNIT_foo is
specified, you get output like:select current_setting('worker_spi.naptime');
current_setting
-----------------
10sand, if you set it for, say, 120000ms or 180min, it will be
displayed as 2min or 3h, etc., making 'seconds' in the text
description a little redundant in the best case—when the
current value is most naturally shown with s—and a little
goofy in the other cases, where the value would be displayed
with min, h, or d, and reading the value combined with the text
description makes the snarky little voice in your head go
"nap for 3 hours seconds??".
Well, you have a point, at that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company