Re: BUG #17161: Assert failed on opening a relation that exists in two schemas via the LANGUAGE SQL function

31.08.2021 05:39, Tom Lane wrote:
> Alexander Lakhin <exclusion(at)gmail(dot)com> writes:
>> My initial conclusion was incorrect. Duplicate relation is not needed in
>> the second schema. It's sufficient to just change search_path to another
>> schema:
> Actually, you don't need to mess with search_path at all: inlining of
> set-returning SQL functions just plain does not work, if they are
> new-style. The reason is that we forgot to apply AcquireRewriteLocks
> in that code path. That leads to the assertion failure you show here.
> Even without that, we risk problems with JOINs on dropped columns, which
> is another thing that AcquireRewriteLocks is charged with cleaning up.
Oops, sorry for the noisy reproduction and incorrect conclusions.
I simplified an initial crashing script (thousand lines generated with a
fuzzer)
but was in hot haste and couldn't think of such a simple explanation.
> The regression tests fail to show this problem because, while they do
> test inlining of a new-style SRF, the solitary test case contains no
> relation references.
>
> I looked around at other places that consult prosqlbody, and saw
> that the only one that accounts for the lock issue is init_sql_fcache.
> fmgr_sql_validator and print_function_sqlbody are also being cavalier
> about this, and I doubt that either one of them is really safe.
> (You could maybe argue that print_function_sqlbody doesn't need locks,
> but in view of the dropped-JOIN-column issue, I don't think I believe
> it. Likewise in fmgr_sql_validator, which wasn't applying the rewriter
> at all, which I doubt is OK considering the older code path does it.)
>
> Proposed patch attached.
This patch fixes the issue for me. Thank you!

Best regards,
Alexander