Patch applied with newer version is timer.c. Thanks.
---
Magnus Hagander wrote:
Hello!
Here is a patch that implements setitimer() on win32. With this patch
applied, deadlock detection and statement_timeout now
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 acquisitions.
I
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
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 don't see
=?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 any
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.
Why bother
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
