From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Ye olde drop-the-database-you-just-left problem |
Date: | 2007-05-30 17:18:02 |
Message-ID: | 465DB1CA.10204@hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 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 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.
>
> This isn't bulletproof since under high load the other backend might
> not get to quit, but it'd surely reduce the frequency of complaints
> a great deal. And we could take out the ad-hoc sleeps that are done
> in (eg) the contrib regression tests.
>
> Thoughts?
An option could be to add a PQfinishWait() API call, and have psql use
this one when passed a special commandline argument (which if I
understood right this guys "commerercial alternative" had). It might be
useful in other cases as well, but I can't really think of one right now :-)
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-05-30 17:21:25 | Re: Style of file error messages |
Previous Message | Tom Lane | 2007-05-30 17:16:58 | Re: Postmaster startup messages |