| From: | Jason Myers <j(dot)myers(at)brstrat(dot)com> |
|---|---|
| To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Orphaned relations after crash/sigkill during CREATE TABLE |
| Date: | 2020-08-20 20:37:23 |
| Message-ID: | CAFzLwcxNDDn+ipy4cDdJ7zvkPh_ceQ+Sd===93K-aOryKvuzdA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tue, Aug 18, 2020 at 3:49 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:
> So from [1] you are using CREATE TABLE AS. Have you tried with:
>
> BEGIN;
> CREATE TABLE some_table SELECT some_data FROM other_table LIMIT 1 WITH
> NO DATA;
> COMMIT;
>
> The above gets you the table structure, but no data.
>
> BEGIN;
> INSERT into some_table SELECT * FROM other_table;
> COMMIT;
>
> The above populates the table. Have not tested but I'm going to assume
> if you kill the above the problem would not happen or would be fixable
> by DELETE FROM some_table/TRUNCATE some_table;
I was able to implement this, which creates the table quickly in a first
transaction and populates it in a second transaction.
However we were still seeing orphaned files on crash, and I believe I
tracked it down to subsequent CREATE INDEX statements also creating these
orphaned files (if they are running during a crash).
Is that issue known as well? I don't believe I can use the same trick to
sidestep that one...
-Jason
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adrian Klaver | 2020-08-20 20:52:49 | Re: Orphaned relations after crash/sigkill during CREATE TABLE |
| Previous Message | Tom Lane | 2020-08-20 20:16:35 | Re: Misestimate when applying condition like id = id |