Microsecond-based timeouts
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:t47594psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 12:53 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 t47594_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 t47594_1 && git checkout t47594_1Patchset v1 (message #1) is on t47594_1
Hi,
Over in [1]/messages/by-id/CAAKRu_b-q0hXCBUCAATh0Z4Zi6UkiC0k2DFgoD3nC-r3SkR3tg@mail.gmail.com, I thought for a moment that a new function
WaitLatchUs(..., timeout_us, ...) was going to be useful to fix that
bug report, at least in master, until I realised the required Linux
syscall is a little too new (for example RHEL 9 shipped May '22,
Debian 12 is expected to be declared "stable" in a few months). So
I'm kicking this proof-of-concept over into a new thread to talk about
in the next cycle, in case it turns out to be useful later.
There probably isn't too much call for very high resolution sleeping.
Most time-based sleeping is probably bad, but when it's legitimately
used to spread CPU or I/O out (instead of illegitimate use for
polling-based algorithms), it seems nice to be able to use all the
accuracy your hardware can provide, and yet it is still important to
be able to process other kinds of events, so WaitLatchUs() seems like
a better building block than pg_usleep().
One question is whether it'd be better to use nanoseconds instead,
since the relevant high-resolution primitives use those under the
covers (struct timespec). On the other hand, microseconds are a good
match for our TimestampTz which is the ultimate source of many of our
timeout decisions. I suppose we could also consider an interface with
an absolute timeout instead, and then stop thinking about the units so
much.
As mentioned in that other thread, the only systems that currently
seem to be able to sleep less than 1ms through these multiplexing APIs
are: Linux 5.11+ (epoll_pwait2()), FreeBSD (kevent()), macOS (ditto).
Everything else will round up to milliseconds at the kernel interface
(because poll(), epoll_wait() and WaitForMultipleObjects() take those)
or later inside the kernel due to kernel tick rounding. There might
be ways to do better on Windows with separate timer events, but I
don't know.
[1]: /messages/by-id/CAAKRu_b-q0hXCBUCAATh0Z4Zi6UkiC0k2DFgoD3nC-r3SkR3tg@mail.gmail.com
Attachments:
t47594_10001-Support-microsecond-based-timeouts-in-WaitEventSet-A.patchtext/x-patch; charset=US-ASCII; name=0001-Support-microsecond-based-timeouts-in-WaitEventSet-A.patchDownload+128-40
0002-Use-microsecond-based-naps-for-vacuum_cost_delay-sle.patchtext/x-patch; charset=US-ASCII; name=0002-Use-microsecond-based-naps-for-vacuum_cost_delay-sle.patchDownload+4-5
0003-Use-microsecond-based-naps-in-walreceiver.patchtext/x-patch; charset=US-ASCII; name=0003-Use-microsecond-based-naps-in-walreceiver.patchDownload+30-9
Hi,
On 2023-03-13 18:23:02 +1300, Thomas Munro wrote:
One question is whether it'd be better to use nanoseconds instead,
since the relevant high-resolution primitives use those under the
covers (struct timespec). On the other hand, microseconds are a good
match for our TimestampTz which is the ultimate source of many of our
timeout decisions.
It's hard to believe we'll need nanosecond sleeps anytime soon, given that
even very trivial syscalls take on the order of 100ns.
It's not like we couldn't add another function for waiting for nanoseconds at
a later point.
I suppose we could also consider an interface with an absolute timeout
instead, and then stop thinking about the units so much.
That seesm pretty awful to use, and we'd just end up with the same question at
the callsites.
Greetings,
Andres Freund