MIME-Version: 1.0
References: <20260204213032.15bab46b@ardentperf.com> <CAOYmi+nS69LiUExZF=gGZ+NJU-SCNQ59qJTiWtJw96cDdi9iSg@mail.gmail.com>
 <20260205150452.00006167@ardentperf.com> <CAHGQGwHZUmg+r4kMcPYt_Z-txxVX+CJJhfra+qemxKXvAxYbpw@mail.gmail.com>
 <1667818.1770336112@sss.pgh.pa.us> <CAOYmi+=UXHJ2mmY3SXPFAV-79QcSCxM-4015te4Ka-5L_ewsow@mail.gmail.com>
In-Reply-To: <CAOYmi+=UXHJ2mmY3SXPFAV-79QcSCxM-4015te4Ka-5L_ewsow@mail.gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
Date: Fri, 6 Feb 2026 14:36:56 +1300
Message-ID: <CA+hUKGKgXh+wEV9jS=0yhYr1=ExzJZVswNWozJSYYWtijYkctg@mail.gmail.com>
Subject: Re: client_connection_check_interval default value
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Fujii Masao <masao.fujii@gmail.com>, 
	Jeremy Schneider <schneider@ardentperf.com>, 
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, 
	Marat Buharov <marat.buharov@gmail.com>, Greg Sabino Mullane <htamfids@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CA%2BhUKGKgXh%2BwEV9jS%3D0yhYr1%3DExzJZVswNWozJSYYWtijYkctg%40mail.gmail.com>
Precedence: bulk

Some space cadet thoughts I recall wondering about back then: If one
process had all the sockets, I suppose something could watch for
POLLRDHUP/KEV_EOF from all of them and send an interrupt to the owner
to handle in its next CFI, so that we don't have to have every backend
polling its socket.  Once we have a multithreaded server we could try
that, but it might become more reasonable to consider with
hypothetical models of socket management where there are executor
threads that are not tried to a session and socket, which implies a
new bit of architecture handling network events on behalf of sessions.
I suppose in theory it could be the postmaster today (just don't close
the client sockets after fork, and teach the postmaster's main loop to
do that), and I vaguely recall something along those lines being shot
down in some other thread... it might cause some extra contention in
the kernel depending how it's implemented (IDK), but it'd obviously
eat a lot of fd table entries which is probably what killed the
notion... though we'll need that large socket table eventually (and
perhaps we'll pay for it by sharing file fds somehow...).  But either way,
heartbeats might indeed make more sense, whatever the architecture.