On Fri, Sep 22, 2006 at 12:03:46PM -0400, AgentM wrote:
>
> On Sep 22, 2006, at 11:26 , Merlin Moncure wrote:
>
> >On 9/22/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >>Stephen Frost <sfrost@snowman.net> writes:
> >>> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >>>> 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.
> >>
> >>> I agree with having it turned off by default, at least in 8.2.
> >>
> >>Do we have a consensus to do this for 8.2? Or are we going to
> >>leave it
> >>as is? Those are the only two realistic short-term options ...
> >
> >there are plenty of other potentially nasty things (like
> >generate_series and the ! operator). why are advisory_locks handled
> >specially? the way it stands right now is a user with command access
> >can DoS a server after five minutes of research on the web.
> >
> >however, if we decide to lock them, it should be documented as such.
> >
> >advisory locks still show up as 'userlock' in the pg_locks view. does
> >this matter?
>
> I would be more worried about accidental collisions between
> applications. The lock ranges will now need to be in their respective
> application's configuration file in case of collision with another
> app once developers really start using locks for IPC. Ideally, the
> user-level lock functions would take strings instead of integers and
> hash them appropriately, no? Otherwise, someone will end up
> maintaining a registry of lock numbers in use. LISTEN doesn't use
> integers.
This is why I suggested we set aside some range of numbers that should
not be used. Doing so would allow adding a better-managed
numbering/naming scheme in the future.
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
