From: | "Dan Armbrust" <daniel(dot)armbrust(dot)list(at)gmail(dot)com> |
---|---|
To: | "Alvaro Herrera" <alvherre(at)commandprompt(dot)com> |
Cc: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>, "pgsql general" <pgsql-general(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Drop database / database in use question |
Date: | 2008-10-17 15:55:19 |
Message-ID: | 82f04dc40810170855o71909fdx719a8f7ac66c85ca@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
It would seem that way. But if you have ever tried programming with
the constraints of an InstallAnywhere installer, you would know why :)
On Fri, Oct 17, 2008 at 10:43 AM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Dan Armbrust escribió:
>> I don't suppose that there is any easy way way that I can stop and/or
>> disable the Autovac temporarily for the database that I want to drop.
>>
>> The only thing that I have seen so far, is that I would have to add
>> rows to the pg_autovacuum table for each table in my database, but
>> I'm not confident that that would even stop it from accessing the
>> database, since it says that even when set to disabled, autovacuum
>> will still run to prevent transaction id wraparounds, so it seems that
>> it still would make make a quick check into the database that my drop
>> command could collide with.
>
> You seem to want to go to a lot of trouble just to a void a simple retry
> loop.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>
From | Date | Subject | |
---|---|---|---|
Next Message | Lincoln Yeoh | 2008-10-17 16:12:02 | Re: Drupal and PostgreSQL - performance issues? |
Previous Message | Alvaro Herrera | 2008-10-17 15:43:06 | Re: Drop database / database in use question |