| From: | Evgeny Morozov <postgresql3(at)realityexists(dot)net> |
|---|---|
| To: | Kirk Wolak <wolakk(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: "PANIC: could not open critical system index 2662" - twice |
| Date: | 2023-05-10 13:32:16 |
| Message-ID: | 0102018805dccbb2-3a9e7116-600d-47cb-8207-6e67f9619123-000000@eu-west-1.amazonses.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 10/05/2023 6:39 am, Kirk Wolak wrote:
> It could be as simple as creating temp tables in the other database
> (since I believe pg_class was hit).
We do indeed create temp tables, both in other databases and in the ones
being tested. (We also create non-temp tables there.)
>
> Also, not sure if the OP has a set of things done after he creates the
> DB that may help?
Basically we read rows from the source database, create some partitions
of tables in the target database, insert into a temp table there using
BULK COPY, then using a regular INSERT copy from the temp tables to the
new partitions.
Now that the probem has been reproduced and understood by the PG
developers, could anyone explain why PG crashed entirely with the
"PANIC" error back in April when only specific databases were corrupted,
not any global objects necesary for PG to run? And why did it not crash
with the "PANIC" on this occasion?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marc Millas | 2023-05-10 14:35:04 | Re: Death postgres |
| Previous Message | Dominique Devienne | 2023-05-10 12:03:33 | Re: Return rows in input array's order? |