Jim Nasby <[EMAIL PROTECTED]> writes:
> How about starting with 5 seconds and seeing if that takes care of
> most situations?
Yeah, I came to that same conclusion ...
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00029.php
regards, tom lane
---
On May 31, 2007, at 1:32 AM, Zeugswetter Andreas ADI SD wrote:
However, it suddenly struck me that we could
probably make most of the problem go away if we put that same wait
into
DROP DATABASE itself --- that is, if we see other backends in the
target DB, sleep for a second or two and then re
Josh Berkus <[EMAIL PROTECTED]> writes:
>> Even if we had a semaphore of the sort you suggest, I doubt people would
>> want DROP DATABASE to wait indefinitely. The real question here is how
>> long is it reasonable for DROP DATABASE to wait before failing ...
> 10 to 15 seconds, I'd say. Is that
> > However, it suddenly struck me that we could
> >probably make most of the problem go away if we put that same wait
into
> >DROP DATABASE itself --- that is, if we see other backends in the
> >target DB, sleep for a second or two and then recheck before erroring
out.
Yup, waiting in drop da
Gregory Stark <[EMAIL PROTECTED]> writes:
> Is there any way to tell, perhaps from the command string, that the process is
> about to start exiting? What stage of exiting is it that we think the kernel
> goes to lunch?
I haven't really done any detailed investigation, but I would think that
a simp
Tom,
> Even if we had a semaphore of the sort you suggest, I doubt people would
> want DROP DATABASE to wait indefinitely. The real question here is how
> long is it reasonable for DROP DATABASE to wait before failing ...
10 to 15 seconds, I'd say. Is that going to be long enough for backends t
"Tom Lane" <[EMAIL PROTECTED]> writes:
> However, it suddenly struck me that we could probably make most of the
> problem go away if we put that same wait into DROP DATABASE itself --- that
> is, if we see other backends in the target DB, sleep for a second or two and
> then recheck before errori
Brian Hurt <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I just finished giving someone the standard advice to wait a bit before
>> trying to drop a database that'd just been accessed:
>> http://archives.postgresql.org/pgsql-general/2007-05/msg01505.php
> Is this a synchronization issue?
The p
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> AFAICT a "real" fix for this would involve making PQfinish() synchronous
>> (don't return till backend is dead), which doesn't seem like a great
>> idea. However, it suddenly struck me that we could probably make most
>> of the probl
Tom Lane wrote:
I just finished giving someone the standard advice to wait a bit before
trying to drop a database that'd just been accessed:
http://archives.postgresql.org/pgsql-general/2007-05/msg01505.php
AFAICT a "real" fix for this would involve making PQfinish() synchronous
(don't return t
Tom Lane wrote:
> I just finished giving someone the standard advice to wait a bit before
> trying to drop a database that'd just been accessed:
> http://archives.postgresql.org/pgsql-general/2007-05/msg01505.php
>
> AFAICT a "real" fix for this would involve making PQfinish() synchronous
> (don't
I just finished giving someone the standard advice to wait a bit before
trying to drop a database that'd just been accessed:
http://archives.postgresql.org/pgsql-general/2007-05/msg01505.php
AFAICT a "real" fix for this would involve making PQfinish() synchronous
(don't return till backend is dead
12 matches
Mail list logo
