Re: Segmentation fault - PostgreSQL 17.0

On 11/11/24 15:22, Ľuboslav Špilák wrote:
> Hello.
> 
>> Could you maybe try on a completely new 17.0 cluster, not one that went
>>through pg_upgrade? I don't think pg_upgrade should cause anything like
>>this, but it'd be good to conclusively rule that out by reproducing the
>>issue on a fresh cluster.
> 
> We can't reproduce the problem on a completely new 17.0 cluster.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00005627752205d5 in heap_compute_data_size
> (tupleDesc=tupleDesc@entry=0x5627a1e1eea0,
> values=values@entry=0x7fff4744a450, isnull=isnull@entry=0x7fff4744a448)
>     at ./build/../src/backend/access/common/heaptuple.c:234
> 234     ./build/../src/backend/access/common/heaptuple.c: No such file
> or directory.
> *(gdb) print i*
> *$1 = 6*
> *(gdb) print numberOfAttributes*
> *$2 = <optimized out>*
> *(gdb) print *tupleDesc*
> *$3 = {natts = 7, tdtypeid = 2249, tdtypmod = 0, tdrefcount = -1, constr
> = 0x0, attrs = 0x5627a1e1eeb8}*
> *(gdb) print *atti*
> *$4 = {attrelid = 0, attname = {data = "value", '\000' <repeats 58
> times>}, atttypid = 25, attlen = -1, attnum = 7, attcacheoff = -1,
> atttypmod = -1, attndims = 0, attbyval = false,*
> *  attalign = 105 'i', attstorage = 120 'x', attcompression = 0 '\000',
> attnotnull = false, atthasdef = false, atthasmissing = false,
> attidentity = 0 '\000', attgenerated = 0 '\000',*
> *  attisdropped = false, attislocal = true, attinhcount = 0,
> attcollation = 100}*

OK, this is really weird - the index you created clearly has just 1
attribute, but this descriptor says there are 7. Which means it likely
accesses garbage outside the actual BRIN tuple - not surprising it
crashes on that.

That tuple descriptor however looks sane, so my guess is you actually
have multiple indexes with the same relname, in a different schemas. And
this finds the wrong one first. That would also explain why it only
happens on an upgraded cluster - the new one won't have the other
indexes, of course.

What does

   SELECT * FROM pg_class WHERE relname = 'test_idxbrin';

say? My bet is it'll return multiple rows, one of which will have 7
attributes.

If this is the case, it's not a bug - as Peter explained, there are some
basic sanity checks, but there's not enough info to check everything. If
you pass a page as bytea with a mismatching index, segfault is expected
(even if unfortunate). It's a power tool - if you hold it wrong, you may
get injured.

One solution is to use fully qualified name of the index, including the
schema. Or always set the search_path.


regards

-- 
Tomas Vondra