Re: BUG #19827: postgres_fdw: Assert in add_foreign_ordered_paths() with redundant ORDER BY in set-op input

On Tue, 3 Nov 2026 at 05:09, Robins Tharakan <tharakan(at)gmail(dot)com> wrote:
> > It fails on master and REL_17_STABLE to REL_19_STABLE; 16 has no
> > setop_pathkeys. On 17 only UNION inputs trip it; from 18 EXCEPT does
> > too (and INTERSECT, tried on master). A patch follows in a reply.
> >
> > The patch (in a reply to this report), is against master 6cda9dfc4f97,
> > and applies through to REL_17_STABLE. In add_foreign_ordered_paths(),
> > the base/join branch now handles the set-operation case first:
>
>
> Here's the patch that fixes the issue.
> It applies from HEAD through REL_17_STABLE. make check passes too.

(I don't seem to have any emails to see what you're replying to here,
and [1] doesn't seem to have any matches apart from your email.)

I think we should fix this in the backbranches by modifying the Assert
to allow sort_pathkeys to be NIL. The human-done v2-0001 patch does
this, plus fixes the incorrect comment just above that was claiming
query_pathkeys must be the same as sort_pathkeys in this scenario.
That should have been updated when I added setop_pathkeys in v17.
Fixing it this way won't result in any plan changes for existing
queries, which is imporant for backpatching.

For master, I propose v2-0002 (also human-done). This effectively does
the same as your v1. What you had was quite clanky which seems to have
resulted in weird logic. I think it's fairly simple; if sort_pathkeys
is NIL, just set fpinfo->pushdown_safe to true, otherwise we can
expect sort_pathkeys to be equal to query_pathkeys.

David

[1] https://www.postgresql.org/search/?m=1&q=19827&l=8&d=-1&s=d