Subject: Re: BUG #17161: Assert failed on opening a relation that exists in
 two schemas via the LANGUAGE SQL function
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@lists.postgresql.org,
 Peter Eisentraut <peter.eisentraut@enterprisedb.com>
References: <17161-048a1cdff8422800@postgresql.org>
 <25f71277-c45a-8ef2-ef9a-9054c3d6e0b0@gmail.com>
 <1568218.1630377575@sss.pgh.pa.us>
From: Alexander Lakhin <exclusion@gmail.com>
Message-ID: <042970a6-8d93-cbb0-0e55-1bfb82a99c1e@gmail.com>
Date: Tue, 31 Aug 2021 07:00:00 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <1568218.1630377575@sss.pgh.pa.us>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
 <https://www.postgresql.org/message-id/042970a6-8d93-cbb0-0e55-1bfb82a99c1e%40gmail.com>
Precedence: bulk

31.08.2021 05:39, Tom Lane wrote:
> Alexander Lakhin <exclusion@gmail.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