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: | Raw Message | Whole Thread | 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? |