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

Поиск
Список
Период
Сортировка
От Alban Hertroys
Тема Re: "PANIC: could not open critical system index 2662" - twice
Дата
Msg-id A312EDE5-838F-4D81-BFA3-C269BAA3F68F@gmail.com
обсуждение исходный текст
Ответ на Re: "PANIC: could not open critical system index 2662" - twice  (Evgeny Morozov <postgresql3@realityexists.net>)
Ответы Re: "PANIC: could not open critical system index 2662" - twice  (Evgeny Morozov <postgresql3@realityexists.net>)
Список pgsql-general
> On 14 Apr 2023, at 9:38, Evgeny Morozov <postgresql3@realityexists.net> wrote:

(…)

> I don't know whether ZFS zero-fills blocks on disk errors. As I
> understood, ZFS should have been able to recover from disk errors (that
> were "unrecoverable" at the hardware level) using the data on the other
> two disks (which did not report any errors). Thus, PG should not have
> seen any corrupted data (if ZFS was working correctly).
> https://unix.stackexchange.com/questions/341614/understanding-the-error-reporting-of-zfs-on-linux
> seems to confirm this. Am I misunderstanding something?

Your problem coincides with a thread at freebsd-current with very similar data corruption after a recent OpenZFS
import:blocks of all zeroes, but also missing files. So, perhaps these problems are related? 

Apparently, there was a recent fix for a data corruption issue with the block_cloning feature enabled, but people are
stillseeing corruption even when they never enabled that feature. 

I couldn’t really find the start of the thread in the archives, so this one kind of jumps into the middle of the thread
ata relevant-looking point: 

https://lists.freebsd.org/archives/freebsd-current/2023-April/003446.html

Regards,

Alban Hertroys
--
There is always an exception to always.







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

Предыдущее
От: Evgeny Morozov
Дата:
Сообщение: Re: "PANIC: could not open critical system index 2662" - twice
Следующее
От: 黄宁
Дата:
Сообщение: cursor with hold must be save to disk?