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
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
Merlin Moncure [EMAIL PROTECTED] writes:
advisory locks still show up as 'userlock' in the pg_locks view. does
this matter?
I'm disinclined to change that, because it would probably break existing
client-side code for little gain.
regards, tom lane
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.
You don't even have to do any
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
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
On 9/22/06, AgentM [EMAIL PROTECTED] wrote:
I would be more worried about accidental collisions between
applications. The lock ranges will now need to be in their respective
i dont think this argument has merit because the lock is scoped to the
current database. this would only be a problem
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
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.
the whole point about advisory locks is that the provided lock space
is
On Sep 22, 2006, at 12:46 , Merlin Moncure wrote:
On 9/22/06, AgentM [EMAIL PROTECTED] wrote:
I would be more worried about accidental collisions between
applications. The lock ranges will now need to be in their respective
i dont think this argument has merit because the lock is scoped to
On Fri, Sep 22, 2006 at 12:56:37PM -0400, Merlin Moncure wrote:
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
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.
the whole
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
On Fri, Sep 22, 2006 at 12:56:37PM -0400, Merlin Moncure wrote:
the whole point about advisory locks is that the provided lock space
is unmanaged. for example, in the ISAM system I wrote which hooked
into the acucobol virtual file system
On Fri, Sep 22, 2006 at 01:21:57PM -0400, Merlin Moncure wrote:
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
On Fri, Sep 22, 2006 at 12:56:37PM -0400, Merlin Moncure wrote:
the whole point about advisory locks is that the provided lock space
is unmanaged. for example, in the ISAM system
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
I'm not asking for a defined solution to how to support multiple
different users of locks within the same database. I just want us to set
aside (as in, recommend they not be used) some set of numbers so that in
the future we could recommend a
Merlin Moncure [EMAIL PROTECTED] writes:
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
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.
the whole point about advisory
On Fri, Sep 22, 2006 at 01:42:48PM -0400, Merlin Moncure wrote:
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
I'm not asking for a defined solution to how to support multiple
different users of locks within the same database. I just want us to set
aside (as in, recommend they not be used)
On 9/22/06, Tom Lane [EMAIL PROTECTED] wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
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
On Sep 22, 2006, at 14:11 , Jim C. Nasby wrote:
On Fri, Sep 22, 2006 at 01:21:57PM -0400, Merlin Moncure wrote:
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
On Fri, Sep 22, 2006 at 12:56:37PM -0400, Merlin Moncure wrote:
the whole point about advisory locks is that the provided lock
Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
advisory locks still show up as 'userlock' in the pg_locks view. does
this matter?
I'm disinclined to change that, because it would probably break existing
client-side code for little gain.
I think clarity suggests we should make
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm disinclined to change that, because it would probably break existing
client-side code for little gain.
I think clarity suggests we should make the heading match the feature,
i.e call it advisory rather than userlock. We changed
Jim C. Nasby [EMAIL PROTECTED] writes:
Ahh, ok, I didn't realize that the total lock space was larger than
what's being exposed today. That means we can easily add that stuff in
the future and not break anything, which is all I was looking for.
Yeah --- in particular, we can always add more
* 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
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm disinclined to change that, because it would probably break existing
client-side code for little gain.
I think clarity suggests we should make the heading match the feature,
i.e call it advisory rather than
AgentM [EMAIL PROTECTED] writes:
If I want to use these locks, it seems I will have to hard-code some
offset into each app or hash the schema name and use that as an
offset :( In any case, I can't imagine the wtf? nightmares an
accidental collision would induce.
That depends entirely on
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
(b) we put up that pgfoundry module so that there would be a backward
compatible solution. Won't be very backward compatible if the locks
look different in pg_locks.
But is anyone going to know what userlocks is in 1-2 years? We have
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
(b) we put up that pgfoundry module so that there would be a backward
compatible solution. Won't be very backward compatible if the locks
look different in pg_locks.
But is anyone going to know what userlocks is
On 9/22/06, AgentM [EMAIL PROTECTED] wrote:
Except you can put tables (and pretty much all your other objects)
in a
schema, one that's presumably named after your application. That
greatly
removes the odds of conficts.
Indeed. In our development environment, we store development,
Bruce Momjian [EMAIL PROTECTED] writes:
I don't see the column rename as an
API change issue.
How can you possibly claim it's not an API change?
If you're insistent on this, my recommendation would be to add a new
LOCKTAG value for advisory locks instead of re-using LOCKTAG_USERLOCK.
This
On 9/22/06, Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I don't see the column rename as an
API change issue.
How can you possibly claim it's not an API change?
i dunno, i agree with bruce here. we are just changing the output of
pg_locks a bit reflecting the
Merlin Moncure wrote:
On 9/22/06, Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I don't see the column rename as an
API change issue.
How can you possibly claim it's not an API change?
i dunno, i agree with bruce here. we are just changing the output
Bruce Momjian [EMAIL PROTECTED] writes:
I guess it is a compatibility change, but weighing compatibility against
clarity, I am leaning toward clarity. I assume it is this line that
would be changed:
_(user lock [%u,%u,%u,%u]),
You assume wrong ... that has nothing to do with what
Bruce Momjian [EMAIL PROTECTED] 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
Le jeudi 21 septembre 2006 01:52, Tom Lane a écrit :
Or we could try to do something about limiting the number of such locks
that can be granted, but that seems nontrivial to tackle at such a late
stage of the devel cycle.
Thoughts?
What about reserving some amount of shared_buffers out of
* 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
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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.
Then why not use a GUC (that only an administrator can set) to control
the
One good thing about advisory locks having been in contrib was that they
didn't affect anyone who didn't actually install the module. Now that
we've put those functions in core, I wonder whether we don't need to
face up to the possibility of malicious use. For instance, it's not
very hard to
On Wed, Sep 20, 2006 at 07:52:33PM -0400, Tom Lane wrote:
face up to the possibility of malicious use. For instance, it's not
very hard to create a DoS situation by running the system out of shared
lock table space:
Didn't you just say we don't try and protect against DoS? ;P
The brute
On 9/21/06, Tom Lane [EMAIL PROTECTED] wrote:
One good thing about advisory locks having been in contrib was that they
didn't affect anyone who didn't actually install the module. Now that
we've put those functions in core, I wonder whether we don't need to
face up to the possibility of
All,
I vote for locking down to superuser access (lets be frank here: I
would estimate 90%+ database installatons run with the application as
root) so we are not losing much.
Not in my experience. Note that making them superuser-only pretty much puts
them out of the hands of hosted
Doesn't creating many temp tables in a transaction do the same thing?
---
Josh Berkus wrote:
All,
I vote for locking down to superuser access (lets be frank here: I
would estimate 90%+ database installatons run with
On Wed, 20 Sep 2006, Bruce Momjian wrote:
Doesn't creating many temp tables in a transaction do the same thing?
---
Like this?
jeremyd=# CREATE OR REPLACE FUNCTION testy(n integer) returns integer as $$
BEGIN
EXECUTE
40 matches
Mail list logo
