| From: | Michael Nolan <htfoot(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: problem/bug in drop tablespace? |
| Date: | 2012-05-12 04:03:41 |
| Message-ID: | CAOzAquKdihRutmDBCsnRghPORGuaBe3prRUFBf2znG+oMhG=Vw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, May 11, 2012 at 10:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Well, the question to me is exactly how much good it will do to stop
> deletion of the pg_tablespace entry, if the underlying files are gone.
> I'm having a hard time getting excited about expending cycles on that.
>
There could be multiple reasons why the underlying files are not there,
such as a filesystem that isn't currently mounted for some reason.
It seems prudent to throw an error on drop tablespace if there are
references to that tablespace in the catalog, or perhaps require a 'force'
clause to override any errors, but it probably isn't something most DBAs
would run into very often.
Thanks for figuring it out, Tom.
--
MIke Nolan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2012-05-12 09:27:19 | Re: PL/Python result set slicing broken in Python 3 |
| Previous Message | Tom Lane | 2012-05-12 03:03:05 | Re: problem/bug in drop tablespace? |