Horton

Re: Connection limits/permissions, slotsync workers, etc

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Cc: pgsql-hackers@lists.postgresql.org, Laurenz Albe <laurenz.albe@cybertec.at>
Date: 2024-12-27T20:51:50Z
Lists: pgsql-hackers

Attachments

Also, here's a patch for the rest of what I was talking about.

We'll need to back-patch this given that the CVE-2024-10978 changes
caused these sorts of problems in all branches, but I've not yet
attempted to back-patch.  It looks like it might be a bit painful
thanks to past code churn in these areas.

I didn't do anything about the idea of making rolconnlimit applicable
to superusers.  If we do that at all, it should only be in HEAD.
Also, I got a shade less enthusiastic about it after noting that this
logic is parallel to that for datconnlimit, and it does seems sensible
to allow superusers to ignore datconnlimit.  Maybe it's fine for the
two limits to operate differently, but I'm unsure.

Also, it probably would make sense to rename PGPROC.isBackgroundWorker
to isRegularBackend (inverting the sense of the boolean), but that
doesn't seem like back-patch material either, so I didn't include it
here.  I think we can get away with a subtle adjustment of which
processes that flag is set for in the back branches, but not with
renaming it.

			regards, tom lane

Commits

  1. Replace PGPROC.isBackgroundWorker with isRegularBackend.

  2. Exclude parallel workers from connection privilege/limit checks.

  3. Reserve a PGPROC slot and semaphore for the slotsync worker process.

  4. Try to avoid semaphore-related test failures on NetBSD/OpenBSD.