Re: Segmentation fault - PostgreSQL 17.0 - Mailing list pgsql-bugs
| From | Ľuboslav Špilák |
|---|---|
| Subject | Re: Segmentation fault - PostgreSQL 17.0 |
| Date | |
| Msg-id | VI1PR02MB63335CB681D92A2EA70CA9678A5E2@VI1PR02MB6333.eurprd02.prod.outlook.com Whole thread Raw |
| In response to | Re: Segmentation fault - PostgreSQL 17.0 (Tomas Vondra <tomas@vondra.me>) |
| Responses |
Re: Segmentation fault - PostgreSQL 17.0
|
| List | pgsql-bugs |
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.
I want to check brin index with
Funkcions:
brin_metapage_info .. okbrin_revmap_data .. okbrin_page_items .. sigsegvThis 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 "
Alternatively, you can enable core files, and generate the backtrace "
In Your pg17 db this funkction works correctly?
Thank You. Lubo.
From: Tomas Vondra <tomas@vondra.me>
Sent: Saturday, November 9, 2024 1:01:25 PM
To: Ľuboslav Špilák <lspilak@microstep-hdo.sk>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Subject: Re: Segmentation fault - PostgreSQL 17.0
Sent: Saturday, November 9, 2024 1:01:25 PM
To: Ľuboslav Špilák <lspilak@microstep-hdo.sk>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Subject: Re: Segmentation fault - PostgreSQL 17.0
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
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.
pgsql-bugs by date: