Re: new heapcheck contrib module

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: new heapcheck contrib module
Дата
Msg-id 721BFA83-EA6F-463D-A9DF-CE78A318B73A@enterprisedb.com
обсуждение исходный текст
Ответ на Re: new heapcheck contrib module  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: new heapcheck contrib module  (Mark Dilger <mark.dilger@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: Is Recovery actually paused?
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Deleting older versions in unique indexes to avoid page splits