Re: verify_heapam for sequences?

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: verify_heapam for sequences?
Дата
Msg-id 65B8C20A-2F35-4573-8041-807E2462471F@enterprisedb.com
обсуждение исходный текст
Ответ на verify_heapam for sequences?  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: verify_heapam for sequences?  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список pgsql-hackers

> On Aug 26, 2021, at 3:03 AM, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
>
>
> Is there a reason why contrib/amcheck/verify_heapam.c does not want to run on sequences?  If I take out the checks,
itappears to work.  Is this an oversight?  Or if there is a reason, maybe it could be stated in a comment, at least. 

Testing the corruption checking logic on all platforms is a bit arduous, because the data layout on disk changes with
alignmentdifference, endianness, etc.  The work I did with Tom's help finally got good test coverage across the entire
buildfarm,but that test (contrib/amcheck/t/001_verify_heapam.pl) doesn't work for sequences even on my one platform
(maclaptop). 

I have added a modicum of test coverage for sequences in the attached WIP patch, which is enough to detect sequence
corruptionon my laptop.  It would have to be tested across the buildfarm after being extended to cover more cases.  As
itstands now, it uses blunt force to corrupt the relation, and only verifies that verify_heapam() returns some
corruption,not that it reports the right corruption. 

I understand that sequences are really just heap tables, and since we already test corrupted heap tables, we could
assumethat we already have sufficient coverage.  I'm not entirely comfortable with that, though, because future patch
authorswho modify how tables or sequences work are not necessarily going to think carefully about whether their
modificationsinvalidate that assumption. 


—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company




Вложения

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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Mark all GUC variable as PGDLLIMPORT