Re: amcheck assert failure - Mailing list pgsql-bugs

From Grigory Smolkin
Subject Re: amcheck assert failure
Date
Msg-id e8c4c837-06f8-2246-f6eb-f390cbf80629@postgrespro.ru
Whole thread Raw
In response to Re: amcheck assert failure  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: amcheck assert failure  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-bugs
Hello!

On 04/20/2019 04:30 AM, Peter Geoghegan wrote:

> On Fri, Apr 19, 2019 at 6:15 PM Grigory Smolkin
> <g.smolkin@postgrespro.ru> wrote:
>> Hello, everyone!
>> I was running some automated tests with amcheck on PG11 and encountered
>> following assertion failure:
>>
>> TRAP: FailedAssertion("!((( (&(itup)->t_tid)->ip_posid ) & 0xF000) ==
>> 0)", File: "nbtutils.c", Line: 2168)
> Was the assertion failure on Postgres Pro's fork? I understand that
> there are differences in this exact area on the forked version,
> because it has to deal with two representations -- the fork had
> INCLUDE indexes before the community version, which explicitly
> represents the number of attributes in pivot tuples.
No, it`s vanilla PG11:
db2=# select version();
version
--------------------------------------------------------------------------------------------------------
  PostgreSQL 11.1 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 6.3.1 
20161221 (Red Hat 6.3.1-1), 64-bit
(1 row)
>
> I wouldn't usually ask this, but the failure is very basic. It's hard
> to believe that it would take this long to notice it.
Maybe it wasn't noticed because binaries, shipped to users, usually 
compiled without '--cassert-enable'.
> I also note that you have "fsync = off". I suppose that that might be
> relevant, too.
It`s automated test, instance get inited, filled with data, subjected 
with various tests and deleted in span of several seconds. And no crash 
has happened during this time.

-- 
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company




pgsql-bugs by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: amcheck assert failure
Next
From: "Jonathan S. Katz"
Date:
Subject: Possible to store invalid SCRAM-SHA-256 Passwords