Re: Ye olde drop-the-database-you-just-left problem
От | Magnus Hagander |
---|---|
Тема | Re: Ye olde drop-the-database-you-just-left problem |
Дата | |
Msg-id | 465DB1CA.10204@hagander.net обсуждение исходный текст |
Ответ на | Ye olde drop-the-database-you-just-left problem (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Ye olde drop-the-database-you-just-left problem
|
Список | 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
В списке pgsql-hackers по дате отправления: