Re: advisory locks and permissions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: advisory locks and permissions
Date
Msg-id 29724.1158848576@sss.pgh.pa.us
Whole thread Raw
In response to Re: advisory locks and permissions  (Bruce Momjian <bruce@momjian.us>)
Responses Re: advisory locks and permissions  (Stephen Frost <sfrost@snowman.net>)
Re: advisory locks and permissions  (Kevin Brown <kevin@sysexperts.com>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> Doesn't creating many temp tables in a transaction do the same thing?

True, but it's a tad harder/less likely that you'd accidentally cause
a problem that way.

I'm not sure if I'm crying wolf or whether there's a serious issue.
Certainly, if you have SQL-command access there are plenty of ways
to cause DoS situations of varying levels of severity.

An admin who is concerned about this can revoke public access on the
functions for himself ... but should that be the default out-of-the-box
configuration?  I feel more comfortable with saying "you have to turn
on this potentially-dangerous feature" than with saying you have to turn
it off.

Another reason for restricting access to the advisory-lock functions
is that an uninformed application might take the wrong locks, and
bollix up your intended usage accidentally.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Dave Cramer
Date:
Subject: Index bloat problem in 7.4
Next
From: Andrew Dunstan
Date:
Subject: Re: 'configure --disable-shared' and 'make check'