Re: new heapcheck contrib module - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: new heapcheck contrib module
Date
Msg-id 721BFA83-EA6F-463D-A9DF-CE78A318B73A@enterprisedb.com
Whole thread Raw
In response to Re: new heapcheck contrib module  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: new heapcheck contrib module  (Mark Dilger <mark.dilger@enterprisedb.com>)
List pgsql-hackers

> On Oct 22, 2020, at 7:06 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Oct 22, 2020 at 8:51 AM Robert Haas <robertmhaas@gmail.com> wrote:
>> Committed. Let's see what the buildfarm thinks.
>
> It is mostly happy, but thorntail is not:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=thorntail&dt=2020-10-22%2012%3A58%3A11
>
> I thought that the problem might be related to the fact that thorntail
> is using force_parallel_mode, but I tried that here and it did not
> cause a failure. So my next guess is that it is related to the fact
> that this is a sparc64 machine, but it's hard to tell, since none of
> the other sparc64 critters have run yet. In any case I don't know why
> that would cause a failure. The messages in the log aren't very
> illuminating, unfortunately. :-(
>
> Mark, any ideas what might cause specifically that set of tests to fail?

The code is correctly handling an uncorrupted table, but then more or less randomly failing some of the time when
processinga corrupt table. 

Tom identified a problem with an uninitialized variable.  I'm putting together a new patch set to address it.

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






pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Is Recovery actually paused?
Next
From: Simon Riggs
Date:
Subject: Re: Deleting older versions in unique indexes to avoid page splits