Re: "PANIC: could not open critical system index 2662" - twice

Поиск
Список
Период
Сортировка
От Kirk Wolak
Тема Re: "PANIC: could not open critical system index 2662" - twice
Дата
Msg-id CACLU5mQKBMme_cx2NzNmwFHPr8APjWfrNubM3=9wxA8wnsbjeQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: "PANIC: could not open critical system index 2662" - twice  (Evgeny Morozov <postgresql3@realityexists.net>)
Список pgsql-general
Дерево обсуждения
On Wed, May 10, 2023 at 9:32 AM Evgeny Morozov <postgresql3@realityexists.net> wrote:
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?

I understand the question as:
Why would it PANIC on non-system data corruption, but not on system data corruption?

To which my guess is:
Because System  Data Corruption, on startup is probably a use case, and we want to report, and come up as much as possible.
Whereas the OTHER code did a PANIC simply because it was BOTH unexpected, and NOT Where it was in a place it could move forward.
Meaning it had no idea if it read in bad data, or if it CREATED the bad data.

As a programmer, you will find much more robust code on startup checking than in the middle of doing something else.

But just a guess.  Someone deeper into the code might explain it better.
And you COULD go dig through the source to compare the origination of the error messages?

Kirk...

В списке pgsql-general по дате отправления:

Предыдущее
От: Kirk Wolak
Дата:
Сообщение: Re: order by
Следующее
От: Kirk Wolak
Дата:
Сообщение: Re: huge discrepancy between EXPLAIN cost and actual time (but the table has just been ANALYZED)