| From: | Ron <ronljohnsonjr(at)gmail(dot)com> |
|---|---|
| To: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Why can't I drop a tablespace? |
| Date: | 2021-07-10 16:13:23 |
| Message-ID: | ec1116c6-c0b4-fc8d-6b74-da853ea615d5@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 7/10/21 10:43 AM, Phil Endecott wrote:
> Phil Endecott wrote:
>> Yesterday I had a disk-nearly-full problem, and decided to try to resolve
>> it by moving one large table to a spare disk in a new tablespace:
>>
>> =# create tablespace tempspace location "/db_temp";
>> =# alter table requests set tablespace tempspace;
[snip]
> - Is my idea that these files should have been deleted but weren't
> during the disk-full panic plausible?
>
> - If I do move them away, what will Postgres do if it tries to access
> them and finds they are missing? Is it well-behaved in this case?
>
> - If I move them away, I would try to exercise the database (e.g.
> do variants of "select sum(column1) from table") in some way to make
> sure that it is all functioning. Any suggestions about how best to do
> this?
I'd shut down postgres, rename those files, and then analyzing the relevant
tables after startup. Probably also run amcheck against the relevant
tables' indices.
https://access.crunchydata.com/documentation/amcheck-next/1.5/#interface
--
Angular momentum makes the world go 'round.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Atul Kumar | 2021-07-11 07:05:36 | Re: optimization issue |
| Previous Message | Phil Endecott | 2021-07-10 15:43:01 | Re: Why can't I drop a tablespace? |