From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Lakhin <exclusion@gmail.com>
cc: Michael Paquier <michael@paquier.xyz>,
        Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18014: Releasing catcache entries makes
 schema_to_xmlschema() fail when parallel workers are used
In-reply-to: <defada9d-8bb1-860f-2682-eee03fdc0ab4@gmail.com>
References: <00e24aa6-5d03-99b6-ab41-495a35fc93f6@gmail.com>
 <982076.1689967306@sss.pgh.pa.us>
 <5bd4cbfe-fc71-c576-851d-3bb21ef5c080@gmail.com>
 <20230726.112923.27361680552823861.horikyota.ntt@gmail.com>
 <1821881.1690339317@sss.pgh.pa.us> <ZMCT1rszfKIiNLpk@paquier.xyz>
 <1830960.1690343673@sss.pgh.pa.us> <1389919.1697144487@sss.pgh.pa.us>
 <5df89a35-a985-b287-7210-6ed7d2c31803@gmail.com>
 <defada9d-8bb1-860f-2682-eee03fdc0ab4@gmail.com>
Comments: In-reply-to Alexander Lakhin <exclusion@gmail.com>
	message dated "Sat, 14 Oct 2023 10:00:00 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1762806.1697301357.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 14 Oct 2023 12:35:57 -0400
Message-ID: <1762807.1697301357@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1762807.1697301357%40sss.pgh.pa.us>
Precedence: bulk

Alexander Lakhin <exclusion@gmail.com> writes:
> 13.10.2023 18:00, Alexander Lakhin wrote:
>> I'll try to research/break xxx_is_visible and share my findings tomorro=
w.

> I tried the script based on the initial reproducer [1]:
> ...
> And couldn't get the error, for multiple runs. (Here SELECT oid ... is
> based on the query executed by schema_to_xmlschema().)
> But I could reliably get the error with
> s/pg_table_is_visible(oid)/has_table_privilege (oid, 'SELECT')/.
> So there is a difference between these two functions. And the difference=
 is
> in their costs.

Ah, thanks for poking at it.  I believe the reason for the cost issue
is that your query already has a very selective indexable condition,
so it tends not to bother with a parallel scan.  I removed the
relnamespace condition:

SELECT oid FROM pg_catalog.pg_class WHERE -- relnamespace =3D 1 AND
  relkind IN ('r', 'm', 'v') AND pg_catalog.pg_table_is_visible(oid);

and then I get a parallel plan without messing with the cost, and it
falls over almost immediately (in a CATCACHE_FORCE_RELEASE build,
anyway).

ITERATION 1
ITERATION 2
ERROR:  cache lookup failed for relation 208139
CONTEXT:  parallel worker
ERROR:  cache lookup failed for relation 208471
CONTEXT:  parallel worker
2023-10-14 12:30:24.747 EDT [1762290] ERROR:  cache lookup failed for rela=
tion 208139
2023-10-14 12:30:24.747 EDT [1762266] ERROR:  cache lookup failed for rela=
tion 208139
2023-10-14 12:30:24.782 EDT [1762310] ERROR:  cache lookup failed for rela=
tion 208471
2023-10-14 12:30:24.782 EDT [1762252] ERROR:  cache lookup failed for rela=
tion 208471

So we do need to fix that.

			regards, tom lane