public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tomas Vondra <[email protected]>
To: Ana Almeida <[email protected]>
To: Jim Jones <[email protected]>
To: [email protected] <[email protected]>
Cc: Nuno Azevedo <[email protected]>
Subject: Re: Segmentation fault in PostgreSQL 17.7 during REINDEX TABLE CONCURRENTLY
Date: Thu, 19 Mar 2026 00:42:03 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <VI0PR07MB10718EF78ABE3997751F55E5D974EA@VI0PR07MB10718.eurprd07.prod.outlook.com>
References: <VI0PR07MB10718A4DC292E068C51404AB2974EA@VI0PR07MB10718.eurprd07.prod.outlook.com>
<[email protected]>
<VI0PR07MB10718EF78ABE3997751F55E5D974EA@VI0PR07MB10718.eurprd07.prod.outlook.com>
On 3/18/26 15:54, Ana Almeida wrote:
> Hello Jim,
>
> I didn’t notice that the error showed the schema and table name. For
> confidentiality reasons, could you please not share the schema and table
> name if this is released as a bug?
>
> Here is the information:
>
>
>
> Table
> "myschema.mytable"
>
> Column | Type | Collation | Nullable
> | Default | Storage | Compression | Stats target | Description
>
> --------------------+-----------------------------+-----------
> +----------+---------+----------+-------------+--------------+-------------
>
> id | bigint | | not null
> | | plain | | |
>
> axxxxxx | character varying(32) | | not null
> | | extended | | |
>
> bxx | text | | not null
> | | extended | | |
>
> cxxxxxxx | text | | not null
> | | extended | | |
>
> dxxxxxxxx | text | |
> | | extended | | |
>
> lag_val | text | |
> | | extended | | |
>
> exxxxxxxxxx | text | |
> | | extended | | |
>
> fxxxxxxxxxxxxx | text | |
> | | extended | | |
>
> gxxxxxxxxxxxx | text | |
> | | extended | | |
>
> hxxxxxx | numeric | | not null
> | | main | | |
>
> ixxxxxxxxxxxxxx | numeric | |
> | | main | | |
>
> jxxxxxxxxxxxxxx | numeric | |
> | | main | | |
>
> kxxxxxx | integer | |
> | | plain | | |
>
> lxxxxxxxxxxxx | integer | | not null
> | | plain | | |
>
> mxxxxxxxxxxxxxx | timestamp without time zone | |
> | | plain | | |
>
> nxxxxxxxxxxxxx | timestamp without time zone | |
> | | plain | | |
>
> oxxxxxxxxxxxx | timestamp without time zone | |
> | | plain | | |
>
> pxxxxxxxxxxx | timestamp without time zone | | not null
> | | plain | | |
>
> qr_mydb_id | bigint | |
> | | plain | | |
>
> qxxxxxx | character varying(100) | |
> | | extended | | |
>
> Indexes:
>
> "mytable_pkey" PRIMARY KEY, btree (id)
>
> "idx_lag_val" btree (lag_val)
>
> "idx_mytable_qr_mydb" btree (qr_mydb_id)
>
> Foreign-key constraints:
>
> "fk__mytable__qr_mydb" FOREIGN KEY (qr_mydb_id) REFERENCES
> myschema.qr_mydb(id)
>
> Access method: heap
>
> Options: autovacuum_enabled=true, toast.autovacuum_enabled=true
>
>
>
> Just another note, before we also had the error below in the same
> reindex command. The database didn’t crash when that error happened but
> the reindex failed. After that, we recreated the table.
>
>
>
> ERROR: could not open file "base/179146/184526.4" (target block
> 808464432): previous segment is only 99572 blocks
>
So what was the sequence of events, exactly? You got this "could not
open file" error during REINDEX CONCURRENTLY, you recreated the table
and then it crashed on some later REINDEX CONCURRENTLY?
How did you recreate the table? Did you reload it from a backup or
something else?
>
> We haven’t been able to reproduce the errors again.
>
That suggests it might have been some sort of data corruption, but it's
just a guess. Have you checked the server log if there are any messages
suggesting e.g. storage / memory issues or something like that?
Per the backtrace you shared in the previous message, the segfault
happened here:
#0 0x00000000005d67a8 validate_index_callback (postgres)
#1 0x00000000005738bd btvacuumpage (postgres)
#2 0x0000000000573d8a btvacuumscan (postgres)
#3 0x0000000000573f00 btbulkdelete (postgres)
...
Which is a very heavily exercised code, so I'm somewhat skeptical a bug
would go unnoticed for very long. It's possible, of course. But the
validate_index_callback doesn't do all that much - it just writes the
TID value to a tuplesort / temporary file.
It seems you have the core saved in a file:
> Storage: /var/lib/systemd/coredump/core.postgres.26.0a32...
Can you try inspecting getting a better backtrace using gdb? It might
tell us if there's a bogus pointer or something like that. Or maybe not,
chances are the compiler optimized some of the variables, but it's worth
a try.
regards
--
Tomas Vondra
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Segmentation fault in PostgreSQL 17.7 during REINDEX TABLE CONCURRENTLY
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox