From: | Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | [(known) BUG] DELETE/UPDATE more than one row in partitioned foreign table |
Date: | 2025-07-18 15:53:14 |
Message-ID: | 20250718175314.4513c00a@karst |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi all,
We have been bitten by this old bug recently:
I suspect this bug lost attention when the only fixed submitted to the
commitfest has been flagged as "returned with feedback":
https://commitfest.postgresql.org/patch/1819/
Please, find in attachment the old patch forbidding more than one row to be
deleted/updated from postgresExecForeignDelete and postgresExecForeignUpdate. I
just rebased them without modification. I suppose this is much safer than
leaving the FDW destroy arbitrary rows on the remote side based on their sole
ctid.
The original discussion talked about using "WHERE CURRENT OF" with cursors to
update/delete rows but discard it because of performance penalty. As adding
tableoid as a junk clause as been rejected, should we investigate the former?
At least for existing major release?
Or maybe we should just not support foreign table to reference a
remote partitioned table?
I'm afraid other fix suggestions from 2018-2019 couldn't be backported as they
seem to require additional feature in FDW altogether. This might be another
reason this bug has been forgotten.
Regards,
Attachment | Content-Type | Size |
---|---|---|
v3-0001-Test-exposing-bug-when-foreign-table-points-to-a-.patch | text/x-patch | 10.2 KB |
v3-0002-Error-out-if-one-iteration-of-non-direct-DML-affe.patch | text/x-patch | 5.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2025-07-18 16:05:04 | Re: Horribly slow pg_upgrade performance with many Large Objects |
Previous Message | Joel Jacobson | 2025-07-18 15:51:47 | Re: Proposal: Out-of-Order NOTIFY via GUC to Improve LISTEN/NOTIFY Throughput |