Re: [PATCHES] NO WAIT ...

2004-06-03 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Why? You can do a SELECT FOR UPDATE first and then you know that you >> have the row lock. There's no need for any special handling of UPDATE >> or DELETE. I don't see the applicability to VACUUM, either. > Why bother when you can d

Re: [PATCHES] NO WAIT ...

2004-02-18 Thread Bruce Momjian
Hans-Jürgen Schönig wrote: > Tom Lane wrote: > > =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes: > > > >>The problem with adding NO WAIT to specific commands is that is > >>inheritly unflexible. I think this is why the community has agreed on > >>implementing it based on GUC

Re: [PATCHES] NO WAIT ...

2004-02-18 Thread Hans-Jürgen Schönig
Tom Lane wrote: =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes: The problem with adding NO WAIT to specific commands is that is inheritly unflexible. I think this is why the community has agreed on implementing it based on GUC. I recall no such agreement ... when was this

Re: [PATCHES] NO WAIT ...

2004-02-18 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> Why? You can do a SELECT FOR UPDATE first and then you know that you > >> have the row lock. There's no need for any special handling of UPDATE > >> or DELETE. I don't see the applicability to VACUUM, either. >

Re: [PATCHES] NO WAIT ...

2004-02-18 Thread Tom Lane
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes: > The problem with adding NO WAIT to specific commands is that is > inheritly unflexible. I think this is why the community has agreed on > implementing it based on GUC. I recall no such agreement ... when was this exactly? In

Re: [PATCHES] NO WAIT ...

2004-02-18 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I imagine folks would want it on UPDATE, DELETE, and VACUUM FULL too, > > Why? You can do a SELECT FOR UPDATE first and then you know that you > have the row lock. There's no need for any special handling of UPDATE > or DELETE. I d

Re: [PATCHES] NO WAIT ...

2004-02-18 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > I imagine folks would want it on UPDATE, DELETE, and VACUUM FULL too, Why? You can do a SELECT FOR UPDATE first and then you know that you have the row lock. There's no need for any special handling of UPDATE or DELETE. I don't see the applicability t

Re: [PATCHES] NO WAIT ...

2004-02-18 Thread Hans-Jürgen Schönig
Tom, Yes, it can be dangerous. I am aware of that. The problem with adding NO WAIT to specific commands is that is inheritly unflexible. I think this is why the community has agreed on implementing it based on GUC. I have done some testing with a real world application. As far as I can see it d

Re: [PATCHES] NO WAIT ...

2004-02-18 Thread Bruce Momjian
Tom Lane wrote: > =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes: > > i have attached a patch implementing NO WAIT with the help of a GUC > > variable. > > I consider this patch incredibly dangerous, as it affects *every* lock > taken, including system internal lock acquisiti

Re: [PATCHES] NO WAIT ...

2004-02-18 Thread Tom Lane
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes: > i have attached a patch implementing NO WAIT with the help of a GUC > variable. I consider this patch incredibly dangerous, as it affects *every* lock taken, including system internal lock acquisitions. I think it might be re