Default client_connection_check_interval to 10s on supported systems
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:t48017psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 12:31 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 t48017_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 t48017_1 && git checkout t48017_1Patchset v1 (message #1) is on t48017_1
Hi,
I am proposing that the default value of
client_connection_check_interval be moved to a non-zero value on
systems where it is supported. I think it would be a nice quality of
life improvement. I have run into a problem where this would have been
useful before with regard to pgbench not currently handling SIGINT
corrently[0]/messages/by-id/CSSWBAX56CVY.291H6ZNNHK7EO@c3po. I basically picked 10s out of thin air and am happy to
change it to what others feel would be more appropriate. This doesn't
need to be a check that happens often because it should just be a
backstop for unusual scenarios or poorly programmed clients.
The original thread where Thomas committed these changes seemed to
indicate no performance impact[1]/messages/by-id/CA+hUKG++KitzNUOxW2-koB1pKWD2cyUqA9vLj5bf0g_i7L1M0w@mail.gmail.com. The only reason that I can think of
this being turned off by default is that it isn't available on all
systems that Postgres supports. When this was committed however, the
only system that seemed to support EPOLLRDHUP was Linux. Seems like in
recent years this story has changed given the description of the
parameter.
This option relies on kernel events exposed by Linux, macOS, illumos and
the BSD family of operating systems, and is not currently available on
other systems.
[0]: /messages/by-id/CSSWBAX56CVY.291H6ZNNHK7EO@c3po
[1]: /messages/by-id/CA+hUKG++KitzNUOxW2-koB1pKWD2cyUqA9vLj5bf0g_i7L1M0w@mail.gmail.com
--
Tristan Partin
Neon (https://neon.tech)
"Tristan Partin" <tristan@neon.tech> writes:
I am proposing that the default value of
client_connection_check_interval be moved to a non-zero value on
systems where it is supported. I think it would be a nice quality of
life improvement.
I doubt that we need this, and I *really* doubt that it's appropriate
to use a timeout as short as 10s.
One reason not to try to enable it by default is exactly that the
default behavior would then be platform-dependent. That's a
documentation problem we could do without.
regards, tom lane
On Fri Jun 16, 2023 at 5:10 PM CDT, Tom Lane wrote:
"Tristan Partin" <tristan@neon.tech> writes:
I am proposing that the default value of
client_connection_check_interval be moved to a non-zero value on
systems where it is supported. I think it would be a nice quality of
life improvement.I doubt that we need this, and I *really* doubt that it's appropriate
to use a timeout as short as 10s.
Sure. Like I said, 10s is just a number pulled from thin air. The
original patches on the mailing list had this as low as 1s.
One reason not to try to enable it by default is exactly that the
default behavior would then be platform-dependent. That's a
documentation problem we could do without.
Totally fine with me if this is the reason for rejection. Just wanted to
put it out there for discussion since I don't think the original thread
covered the default value very much.
--
Tristan Partin
Neon (https://neon.tech)