From: | "Jim Buttafuoco" <jim(at)contactbda(dot)com> |
---|---|
To: | "Tony Wasson" <ajwasson(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: drop database command blocking other connections |
Date: | 2006-05-03 21:18:24 |
Message-ID: | 20060503211734.M15686@contactbda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
nice workaround, I am going to modify my procedure to drop the "public" schema first (it is the largest one).
---------- Original Message -----------
From: "Tony Wasson" <ajwasson(at)gmail(dot)com>
To: jim(at)contactbda(dot)com
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Sent: Wed, 3 May 2006 14:09:05 -0700
Subject: Re: [HACKERS] drop database command blocking other connections
> On 5/3/06, Jim Buttafuoco <jim(at)contactbda(dot)com> wrote:
> > from time to time I have to drop a very large database (1TB+). The drop database command takes a long time to
complete
> > while its deleting the files. During this time, no one can connect to the database server, ps displays "startup
> > waiting". This is with Postgresql 7.4. Has this been addressed in 8.1, if not, does anyone have some ideas on
how to
> > speed this up.
>
> I don't have a "fix", but I can offer a workaround.
>
> When we need to drop large DBs we drop them a schema at a time. DROP
> SCHEMA does *not* block new connections into the server. Once the data
> it out of the schema(s), a DROP DATABASE on a nearly empty database
> does not block new connections for more than a moment.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
------- End of Original Message -------
From | Date | Subject | |
---|---|---|---|
Next Message | Nikolay Samokhvalov | 2006-05-03 21:46:44 | Re: [SoC] Relation between project "XML improvements" and "pgxml" |
Previous Message | Tony Wasson | 2006-05-03 21:09:05 | Re: drop database command blocking other connections |