Re: amcheck assert failure

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: amcheck assert failure
Дата
Msg-id CAH2-WzkotO_ueP55Up2ZfHi+JehzgkU5rCH3WiQ6q3kNo+G1nw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: amcheck assert failure  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
On Mon, Apr 22, 2019 at 1:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> No objection here, as long as it doesn't add an unreasonable amount
> of complexity.  (If it does, we might have to think harder about
> what to do.)

Attached is a draft patch that adds a PageGetItemId() wrapper called
PageGetItemIdCareful(), and has amcheck use it consistently. This does
two basic sanity checks that seem very likely to avoid the kind of
misbehaviors that result in a crash (including assertion failures)
when amcheck is used.

This is a bit more complicated than I'd hoped, because it is necessary
to call PageGetItemIdCareful() before _bt_compare() and other core
code in a way that wouldn't quite look right with raw PageGetItemId()
calls. _bt_compare() will do its own PageGetItemId(), and will itself
assert !bt_check_natts() (which was the issue in Grigory's problem
report), so we need to make sure that that will be safe ahead of time.
Even still, it doesn't seem too complicated to me.

-- 
Peter Geoghegan

Вложения

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

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #15778: Replication slot peak query cause memory spike at the server when big transaction are running
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: CREATE SUBSCRIPTION fails with long passwords