Re: Segmentation fault - PostgreSQL 17.0 - Mailing list pgsql-bugs

On 11/8/24 18:22, Ľuboslav Špilák wrote:
> Hello.
> 
> I am trying postgresql17 partitioning tables and check brin indexes with
> error* Segmenation fault.* 
> We upgraded db from last PostgreSQL12 to 17.0 using pg_upgrade binary.
> Everything seems to be OK. Only this select is problem.
>    
> select * from brin_page_items(
>           get_raw_page('test1_table_2022q3_timeseries_id_time_idx',2),
>           'test1_table_2022q3_timeseries_id_time_idx'
>         )
> 
> Welcome to *Ubuntu 20.04.6 *LTS (GNU/Linux 5.4.0-200-generic x86_64)
> *PostgreSQL 17.0* (Ubuntu 17.0-1.pgdg20.04+1) on x86_64-pc-linux-gnu,
> compiled by gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0, 64-bit
> 
> 
> 2024-11-08 18:12:20.861 CET [12350] LOG:  starting PostgreSQL 17.0
> (Ubuntu 17.0-1.pgdg20.04+1) on x86_64-pc-linux-gnu, compiled by gcc
> (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0, 64-bit
> 2024-11-08 18:12:20.864 CET [12350] LOG:  listening on IPv4 address
> "0.0.0.0", port 5432
> 2024-11-08 18:12:20.867 CET [12350] LOG:  could not create IPv6 socket
> for address "::": Address family not supported by protocol
> 2024-11-08 18:12:20.868 CET [12350] LOG:  listening on Unix socket "/
> var/run/postgresql/.s.PGSQL.5432"
> 2024-11-08 18:12:20.878 CET [12357] LOG:  database system was shut down
> at 2024-11-08 18:12:19 CET
> 2024-11-08 18:12:20.890 CET [12350] LOG:  database system is ready to
> accept connections
> 2024-11-08 18:12:41.055 CET [12350] LOG:  *server process (PID 12376)
> was terminated by signal 11: Segmentation fault*
> 2024-11-08 18:12:41.055 CET [12350] DETAIL:  Failed process was running:
> select *
>         from brin_page_items(
>           get_raw_page('test1_table_2022q3_timeseries_id_time_idx',2),
>           'test1_table_2022q3_timeseries_id_time_idx'
>         )
> 2024-11-08 18:12:41.055 CET [12350] LOG:  terminating any other active
> server processes
> 2024-11-08 18:12:41.058 CET [12350] LOG:  all server processes
> terminated; reinitializing
> 2024-11-08 18:12:41.276 CET [12379] LOG:  database system was
> interrupted; last known up at 2024-11-08 18:12:20 CET
> 2024-11-08 18:12:41.293 CET [12382] postgres@xtimeseries FATAL:  the
> database system is in recovery mode
> 2024-11-08 18:12:41.319 CET [12383] postgres@xtimeseries FATAL:  the
> database system is in recovery mode
> 2024-11-08 18:12:41.346 CET [12384] postgres@xtimeseries FATAL:  the
> database system is in recovery mode
> 2024-11-08 18:12:41.364 CET [12379] LOG:  database system was not
> properly shut down; automatic recovery in progress
> 2024-11-08 18:12:41.371 CET [12379] LOG:  redo starts at FE49/7A5FBCD0
> 2024-11-08 18:12:41.371 CET [12379] LOG:  invalid record length at
> FE49/7A5FBD08: expected at least 24, got 0
> 2024-11-08 18:12:41.371 CET [12379] LOG:  redo done at FE49/7A5FBCD0
> system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
> 2024-11-08 18:12:41.371 CET [12385] postgres@xtimeseries FATAL:  the
> database system is in recovery mode
> 2024-11-08 18:12:41.384 CET [12380] LOG:  checkpoint starting: end-of-
> recovery immediate wait
> 2024-11-08 18:12:41.401 CET [12386] postgres@xtimeseries FATAL:  the
> database system is not yet accepting connections
> 2024-11-08 18:12:41.401 CET [12386] postgres@xtimeseries DETAIL:
>  Consistent recovery state has not been yet reached.
> 2024-11-08 18:12:41.408 CET [12380] LOG:  checkpoint complete: wrote 2
> buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.017
> s, sync=0.002 s, total=0.026 s; sync files=3, longest=0.001 s,
> average=0.001 s; distance=0 kB, estimate=0 kB; lsn=FE49/7A5FBD08, redo
> lsn=FE49/7A5FBD08
> 2024-11-08 18:12:41.413 CET [12350] LOG:  database system is ready to
> accept connections
> 
> What could be wrong?

Hard to say, really. It would be interesting to see the backtrace from
the crash.

Considering you're able to trigger the issue easily, it shouldn't be too
difficult to attach GDB to a backend before running the query.
Alternatively, you can enable core files, and generate the backtrace
from that.

Presumably the index is a simple BRIN minmax index? Or what opclass does
it use? Any special parameters? Is the index working otherwise,
producing correct results?


regards

-- 
Tomas Vondra