Re: new heapcheck contrib module
От | Mark Dilger |
---|---|
Тема | Re: new heapcheck contrib module |
Дата | |
Msg-id | 845CE380-9DCE-4625-AD43-C680E690A617@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: new heapcheck contrib module (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: new heapcheck contrib module
|
Список | pgsql-hackers |
> On Oct 22, 2020, at 1:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Mark Dilger <mark.dilger@enterprisedb.com> writes: >>> On Oct 22, 2020, at 1:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> ooh, looks like prairiedog sees the problem too. That means I should be >>> able to reproduce it under a debugger, if you're not certain yet where >>> the problem lies. > >> Thanks, Tom, but I question whether the regression test failures are from a problem in the verify_heapam.c code. I thinkthey are a busted perl test. The test was supposed to corrupt the heap by overwriting a heap file with a large chunkof garbage, but in fact only wrote a small amount of garbage. The idea was to write about 2000 bytes starting at offset32 in the page, in order to corrupt the line pointers, but owing to my incorrect use of syswrite in the perl test,that didn't happen. > > Hm, but why are we seeing the failure only on specific machine > architectures? sparc64 and ppc32 is a weird pairing, too. It is seeking to position 32 and writing '\x77\x77\x77\x77'. x86_64 is little-endian, and ppc32 and sparc64 are both big-endian,right? — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: