Re: BUG #19484: Segmentation fault triggered by FDW

Richard Guo <guofenglinux@gmail.com>

From: Richard Guo <guofenglinux@gmail.com>

To: Amit Langote <amitlangote09@gmail.com>

Cc: Etsuro Fujita <etsuro.fujita@gmail.com>, Matheus Alcantara <matheusssilv97@gmail.com>, Ayush Tiwari <ayushtiwari.slg01@gmail.com>, Rafia Sabih <rafia.pghackers@gmail.com>, 798604270@qq.com, pgsql-bugs@lists.postgresql.org, Amit Langote <amitlan@postgresql.org>

Date: 2026-06-24T02:23:12Z

Lists: pgsql-bugs

On Wed, Jun 24, 2026 at 10:43 AM Amit Langote <amitlangote09@gmail.com> wrote:
> If we’d rather avoid it, I have a no-field alternative for REL_18: show_modifytable_info() is the only reader of the re-indexed list, and it can recompute the mapping from node->resultRelations and node->fdwPrivLists, both plan-ordered and untouched by pruning.

This sounds like a nice solution.  Since show_modifytable_info() is
only used for EXPLAIN, I guess the recompute overhead on the
re-indexed list should be fine.

- Richard

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Avoid ABI break in ModifyTableState from the FDW pruning fix
- bba4e095d250 18 (unreleased) landed
Re-index ModifyTable FDW arrays when pruning result relations
- b43f8aa4cb30 19 (unreleased) landed
- 1ef917e3a61a 18 (unreleased) landed
Fix universal builds on MacOS
- 901ed9b352b4 19 (unreleased) cited
Track unpruned relids to avoid processing pruned relations
- cbc127917e04 18.0 cited