reserved_superuser_connections tweak

Started by Neil Conwayover 23 years ago2 messagespatches
Jump to latest
#1Neil Conway
neilc@samurai.com

There's no point counting the # of empty backend slots (which requires
grabbing an LWLock) unless

(a) the # of reserved slots is > 0

(b) the current user is not a superuser

Thus, we can sometimes get away without grabbing the lock

Cheers,

Neil

--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC

Attachments:

reserved_conn_fix-1.patchtext/x-patchDownload+21-21
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Neil Conway (#1)
Re: reserved_superuser_connections tweak

Neil Conway <neilc@samurai.com> writes:

--=-=-=
There's no point counting the # of empty backend slots (which requires
grabbing an LWLock) unless
(a) the # of reserved slots is > 0
(b) the current user is not a superuser
Thus, we can sometimes get away without grabbing the lock

Good point. OTOH, superuser() is not necessarily a cheap function
either. If the user's pg_shadow row hasn't yet been loaded into the
SHADOWSYSID cache, it will provoke a catalog row fetch cycle, which will
cost *way* more than one measly LWLock. I'm not sure whether that's
likely to be the case though --- have you checked where that cache entry
first gets loaded in a typical startup?

A more serious problem with this code, now that I look at it, is that it
is risking a catalog fetch cycle outside of any transaction. That is a
Big No-No.

regards, tom lane