Re: Segmentation fault - PostgreSQL 17.0

Hello.

After pg_upgrade there was 200 timeseries tables in xtimeseries database.
Each about 2GB with two indexes. One Btree and second brin index. Brin on two columns (timeseries_id, time).

I created copy of one table and try change table to partitioned table, partigioned by time. One quartal to one partition.

Analyse, vacuum table.

Then i figured out it sigsegv on brin_page_items Function repeatedly.

So THEN I try create new test table on pg17. I dont know now if I created table on different database or only on different schema, but on the same db cluster.
Test table with one column with one brin index on that column. Insert only one row. I Vacuumed this test table. I try again sequence of three brin functions to check if brin index is computed. Third function brin_page_items caused sigsegv again.

Thank you.
Best regards,
Lubo

________________________________
From: Tomas Vondra <tomas(at)vondra(dot)me>
Sent: Saturday, November 9, 2024 5:07:48 PM
To: Ľuboslav Špilák <lspilak(at)microstep-hdo(dot)sk>; 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/9/24 14:02, Ľuboslav Špilák wrote:
> Ahoj/Hello.
>
> On migrated db.
> In postgres or public schema (im not sure now) I created the table with
> one column int8 - cas (unixtime)
> Then I create index brin on that column (by cas/unixtime).
> Insert only one row.
> Then I Vacuumed table.
>

So is this a tiny single-row table? Did you create it on PG17, or before
running pg_upgrade?

> I want to check brin index with
> Funkcions:
>
> |brin_metapage_info .. ok|
> |brin_revmap_data .. ok|
> |brin_page_items .. sigsegv|
>
> This is done repeatedly on my migrated db.
>
> On Monday I could try create new cluster / empty database and try the
> same again.
>
> I must google it to know how:
> "attach GDB to a backend before running the query.
> Alternatively, you can enable core files, and generate the backtrace "
>

There are wiki pages [1] and [2] with instructions how to do this. But
in short, connect to the DB, get PID using

SELECT pg_backend_pid();

attach gdb to that backend

gdb -p $PID

Hit 'c' to continue running the program, and run the crashing query in
the client. The gdb session will interrupt on the segfault, and you'll
be able to get backtrace by 'bt'.

> In Your pg17 db this funkction works correctly?
>

It works for me, yes. this is what I tried:

create table t (a bigint);
insert into t values (1);
create index on t using brin (a);

select * from brin_metapage_info(get_raw_page('t_a_idx', 0));
magic | version | pagesperrange | lastrevmappage
------------+---------+---------------+----------------
0xA8109CFA | 1 | 128 | 1
(1 row)

select * from brin_revmap_data(get_raw_page('t_a_idx', 1));
pages
-------
(2,1)
(0,0)
(0,0)
...

select * from brin_page_items(get_raw_page('t_a_idx', 2), 't_a_idx');
itemoffset | blknum | attnum | allnulls | hasnulls | placeholder |
empty | value
------------+--------+--------+----------+----------+-------------+-------+----------
1 | 0 | 1 | f | f | f | f
| {1 .. 1}
(1 row)

But this is just a very simple test.

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.