Re: Segmentation fault - PostgreSQL 17.0

Hello.

Updating pageinspect helped. The function is not crashing anymore.

Before update pageinspect

[Tue Nov 12](09:06)# su postgres
postgres(at)hdoppxendb1:/home/ladmin$ psql -d xtimeseries
psql (17.0 (Ubuntu 17.0-1.pgdg20.04+1))
Type "help" for help.

xtimeseries=# \conninfo
You are connected to database "xtimeseries" as user "postgres" via socket in "/v ar/run/postgresql" at port "5432".
xtimeseries=# \df brin_page_items
List of functions
Schema | Name | Result data type | Argument data types | Type
--------+------+------------------+---------------------+------
(0 rows)

xtimeseries=# select * from pg_extension;
oid | extname | extowner | extnamespace | extrelocatable | extversion | extconfig | extcondition
-------+-------------+----------+--------------+----------------+------------+-----------+--------------
13515 | plpgsql | 10 | 11 | f | 1.0 | |
16831 | pg_repack | 10 | 16830 | f | 1.5.1 | |
16833 | pageinspect | 10 | 16830 | t | 1.7 | |
(3 rows)

After update pageinspect

[Tue Nov 12](09:11)# su postgres
postgres(at)hdoppxendb1:/home/ladmin$ psql -d xtimeseries
psql (17.0 (Ubuntu 17.0-1.pgdg20.04+1))
Type "help" for help.

xtimeseries=# \dx
List of installed extensions
Name | Version | Schema | Description
-------------+---------+------------+--------------------------------------------------------------
pageinspect | 1.12 | XEN_TS | inspect the contents of database pages at a low level
pg_repack | 1.5.1 | XEN_TS | Reorganize tables in PostgreSQL databases with minimal locks
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)

xtimeseries=# \df brin_page_items
List of functions
Schema | Name | Result data type | Argument data types | Type
--------+------+------------------+---------------------+------
(0 rows)

xtimeseries=#

Thank you very much.

Best regards, Lubo
________________________________
From: Ľuboslav Špilák <lspilak(at)microstep-hdo(dot)sk>
Sent: Monday, 11 November 2024 18:11
To: Tomas Vondra <tomas(at)vondra(dot)me>; Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Segmentation fault - PostgreSQL 17.0

Hello.

Yes we have the old version 1.7 as I sent before:

[Image]

I will try your recommendations tomorrow.
Thank you very much for your help.

Best regards, Lubo
________________________________
From: Tomas Vondra <tomas(at)vondra(dot)me>
Sent: Monday, November 11, 2024 5:22:13 PM
To: Ľuboslav Špilák <lspilak(at)microstep-hdo(dot)sk>; Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Segmentation fault - PostgreSQL 17.0

On 11/11/24 16:20, Ľuboslav Špilák wrote:
> Hello.
>
> I had similar ly created table in a different schema, so there were
> truly 2 rows in the given select (but the 2^nd one was created to test
> the problem), so even after removing one of them the problem still
> persists.
>
> *select* * *from* pg_class *where* relname='test_idxbrin';
> "oid","relname","relnamespace","reltype","reloftype","relowner","relam","relfilenode","reltablespace","relpages","reltuples","relallvisible","reltoastrelid","relhasindex","relisshared","relpersistence","relkind","relnatts","relchecks","relhasrules","relhastriggers","relhassubclass","relrowsecurity","relforcerowsecurity","relispopulated","relreplident","relispartition","relrewrite","relfrozenxid","relminmxid","relacl","reloptions","relpartbound"
> 1128187015,test_idxbrin,2200,0,0,10,3580,1128187015,0,3,0.0,0,0,false,false,p,i,1,0,false,false,false,false,false,true,n,false,0,"0","0",,{pages_per_range=32},
> 1128178819,test_idxbrin,16830,0,0,10,3580,1128178819,0,3,0.0,0,0,false,false,p,i,1,0,false,false,false,false,false,true,n,false,0,"0","0",,{pages_per_range=32},
>
> So we removed one of the tables with this index and now this select
> returned one row
>
> *select* * *from* pg_class *where* relname='test_idxbrin';
> "oid","relname","relnamespace","reltype","reloftype","relowner","relam","relfilenode","reltablespace","relpages","reltuples","relallvisible","reltoastrelid","relhasindex","relisshared","relpersistence","relkind","relnatts","relchecks","relhasrules","relhastriggers","relhassubclass","relrowsecurity","relforcerowsecurity","relispopulated","relreplident","relispartition","relrewrite","relfrozenxid","relminmxid","relacl","reloptions","relpartbound"
> 1128178819,test_idxbrin,16830,0,0,10,3580,1128178819,0,3,0.0,0,0,false,false,p,i,1,0,false,false,false,false,false,true,n,false,0,"0","0",,{pages_per_range=32},
>
>
> Then we called the problematic function again and it crashed.
>

Ah, I see. I've been looking at this assuming the descriptor is for the
index, when in fact it's for the result, which actually has more
attributes (so my comment about the index having just 1 attribute was
misguided).

But now I noticed an interesting thing - if I print the descriptor in
heap_compute_data_size, I get this:

(gdb) p *tupleDesc
$1 = {natts = 8, tdtypeid = 2249, tdtypmod = 0, tdrefcount = -1, constr
= 0x0, attrs = 0xb2d29b0}

There's 8 attributes, not 7 (which is what you get).

Well, the reason is likely pretty simple - I'd bet you have pageinspect
at version 1.11 (or older), which didn't know about empty ranges. And
1.12 added that, and the C code dutifully fills that. But the descriptor
is derived from the function signature, and that doesn't have that
attribute. So it tries to interpret 0 (=false) as a pointer, and that
just segfaults.

If you do \dx (or select * from pg_extension), what version you get for
pageinspect? And if you do "\df brin_page_items" does it have "empty" as
one of the output arguments?

You can try "alter extension pageinspect update" to update the function
signatures, etc. That should make the segfault go away.

I can reproduce this by installing pageinspect 1.11 and running the
brin_page_items() query. What a stupid bug, I should have thought about
this when adding the "empty" field.

Thanks for the report!

regards

--
Tomas Vondra

________________________________

Textom tejto emailovej správy odosielateľ nesľubuje ani neuzatvára za spoločnosť MicroStep - HDO s.r.o. žiadnu zmluvu, nakoľko naša spoločnosť uzatvára každú zmluvu výlučne v písomnej forme. Ak Vám bol tento e-mail zaslaný omylom, prosím upozornite odosielateľa a tento e-mail odstráňte.

The sender of this e-mail message does not promise nor shall conclude any contract on the behalf of the company MicroStep HDO s.r.o. as our company enters into any contract exclusively in writing. If you have been sent this email in error, please notify the sender and delete this email.