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 <[EMAIL PROTECTED]> wrote: > >>Stephen Frost <[EMAIL PROTECTED]> writes: > >>> * Tom Lane ([EMAIL PROTECTED]) 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 [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly