| 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 |
| 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. |