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 tomorrow.
> 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 = 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 relation 208139
2023-10-14 12:30:24.747 EDT [1762266] ERROR: cache lookup failed for relation 208139
2023-10-14 12:30:24.782 EDT [1762310] ERROR: cache lookup failed for relation 208471
2023-10-14 12:30:24.782 EDT [1762252] ERROR: cache lookup failed for relation 208471
So we do need to fix that.
regards, tom lane
