RE: Segmentation fault in PostgreSQL 17.7 during REINDEX TABLE CONCURRENTLY

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

We haven’t been able to reproduce the errors again.

Cumprimentos,

Ana Almeida

-----Original Message-----
From: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
Sent: 18 March 2026 13:10
To: Ana Almeida <Ana(dot)Almeida(at)timestamp(dot)pt>; pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Segmentation fault in PostgreSQL 17.7 during REINDEX TABLE CONCURRENTLY

[You don't often get email from jim(dot)jones(at)uni-muenster(dot)de<mailto:jim(dot)jones(at)uni-muenster(dot)de>. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Ana

On 18/03/2026 10:54, Ana Almeida wrote:

> 2026-03-17 18:19:55.244 WAT [2261667] LOG: server process (PID

> 2382873) was terminated by signal 11: Segmentation fault

>

> 2026-03-17 18:19:55.244 WAT [2261667] DETAIL: Failed process was

> running: REINDEX TABLE CONCURRENTLY sibs.purchases;

>

> 2026-03-17 18:19:55.244 WAT [2261667] LOG: terminating any other

> active server processes

>

> 2026-03-17 18:19:55.257 WAT [2261667] LOG: all server processes

> terminated; reinitializing

>

> 2026-03-17 18:19:55.354 WAT [2382972] LOG: database system was

> interrupted; last known up at 2026-03-17 18:18:58 WAT

>

> 2026-03-17 18:19:55.449 WAT [2382972] LOG: database system was not

> properly shut down; automatic recovery in progress

>

> 2026-03-17 18:19:55.457 WAT [2382972] LOG: redo starts at

> 310/8142BEC0

>

> 2026-03-17 18:19:56.352 WAT [2382972] LOG: invalid record length at

> 310/988BAA18: expected at least 24, got 0

>

> 2026-03-17 18:19:56.352 WAT [2382972] LOG: redo done at 310/988BA9E0

> system usage: CPU: user: 0.28 s, system: 0.34 s, elapsed: 0.89 s

>

> 2026-03-17 18:19:56.360 WAT [2382973] LOG: checkpoint starting:

> end-of- recovery immediate wait

I was unable to reproduce the bug. Could you share a bit more data on the table and indexes that caused the system crash?

Best, Jim