Re: Bypassing cursors in postgres_fdw to enable parallel plans

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru>
Cc: Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>, KENAN YILMAZ <kenan(dot)yilmaz(at)localus(dot)com(dot)tr>, Andy Fan <zhihuifan1213(at)163(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Bypassing cursors in postgres_fdw to enable parallel plans
Date: 2026-10-09 20:08:25
Message-ID: CA+TgmoaOGXa3i=mtRh4M5LPQgHDe20sWQoNtwD2uQFmWousANA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 17, 2025 at 9:09 AM Alexander Pyhalov
<a(dot)pyhalov(at)postgrespro(dot)ru> wrote:
> I've looked at this patch, because also was playing with tuplestore in
> PgFdwScanState to have more predictable memory usage with large
> fetch_size. Unfortunately, I've found that you can't use
> TTSOpsMinimalTuple(?) tuplestore to store tuple's ctid. I hoped this
> patch provides some solution for this issue, but no, it seems have the
> same problem. Attaching test case with a reproducer.

Rafia, the bug that Alexander reports here is still unfixed in the
latest version of the patch. In short, tuplestore_puttuple() doesn't
store the CTID. A standalone, Claude-written test case demonstrating
the problem is attached. One possible way to fix this is to disable
streaming_fetch when CTID is among the columns fetched. If the CTID is
being fetched because we're doing an UPDATE or DELETE, the scan is
going to have to be drained to allow the per-row UPDATE or DELETE
commands to be executed, so streaming-fetch mode is actually a bad
idea anyway.

--
Robert Haas
Databricks

Attachment Content-Type Size
streaming_fetch_ctid.sql application/octet-stream 1.6 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dongpo Liu 2026-10-09 20:19:25 Re: pg_*_advice: tsv load failure, etc.
Previous Message Robert Haas 2026-10-09 19:15:14 Re: pg_*_advice: tsv load failure, etc.