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 wha
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
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 reflectin
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 w
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,
int
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 wh
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?
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 enti
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 "advisor
* 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 f
"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 m
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". W
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 s
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
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/na
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 b
"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 abou
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 me
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 I
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 i
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.
>
>
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 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 unm
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 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
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
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 researc
"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
--
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
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 tu
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 cont
* 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" tha
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
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 SQ
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
EXECUT
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
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 appli
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 malici
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 f
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 crea
40 matches
Mail list logo
