Re: Test publication.sql racing with subscription.sql might fail due to cache lookup error

On Tue, 13 Oct 2026 at 01:30, Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
>
> Hello hackers,
>
> Today tamandua emitted a new failure of publication.sql [1]:
> # diff -U3 /home/bf/bf-build/tamandua/HEAD/pgsql/src/test/regress/expected/publication.out
> /home/bf/bf-build/tamandua/HEAD/pgsql.build/testrun/test_plan_advice/001_replan_regress/data/results/publication.out
> # --- /home/bf/bf-build/tamandua/HEAD/pgsql/src/test/regress/expected/publication.out 2026-09-26 17:11:33.701652728 +0200
> # +++
> /home/bf/bf-build/tamandua/HEAD/pgsql.build/testrun/test_plan_advice/001_replan_regress/data/results/publication.out
> 2026-10-12 11:50:53.473655771 +0200
> # @@ -1349,31 +1349,31 @@
> # DETAIL: Column lists cannot be specified in publications containing FOR TABLES IN SCHEMA elements.
> # -- ok - only publish schema
> # CREATE PUBLICATION testpub_tbl9 FOR TABLES IN SCHEMA public;
> # +ERROR: cache lookup failed for relation 36073
> # -- failure - add a table with column list when there is already a schema in the
> # -- publication
>
> postmaster.log contains:
> 2026-10-12 11:50:51.429 CEST [418046][client backend][98/742:0] LOG: statement: CREATE PUBLICATION testpub_tbl9 FOR
> TABLES IN SCHEMA public;
> 2026-10-12 11:50:51.432 CEST [418061][client backend][99/395:0] LOG: statement: DROP TABLE public.test_move;
> 2026-10-12 11:50:51.436 CEST [418061][client backend][99/396:0] LOG: statement: SET client_min_messages = WARNING;
> 2026-10-12 11:50:51.441 CEST [418046][client backend][98/742:14613] ERROR: cache lookup failed for relation 36073
> 2026-10-12 11:50:51.441 CEST [418046][client backend][98/742:14613] STATEMENT: CREATE PUBLICATION testpub_tbl9 FOR
> TABLES IN SCHEMA public;
>
> I've reproduced this with an isolated script:
> for ((n=1;n<=10;n++)); do
> echo "ITERATION $n"
>
> for i in {1..100}; do echo "
> CREATE TABLE public.test_move (id int);
> DROP TABLE public.test_move;
> "; done | psql >psql_sub.log &
>
> for i in {1..100}; do echo "
> DROP TABLE IF EXISTS testpub_root;
> CREATE TABLE testpub_root(a int) PARTITION BY RANGE(a);
> CREATE TABLE testpub_part1 PARTITION OF testpub_root FOR VALUES FROM (0) TO (100);
>
> CREATE PUBLICATION testpub_tbl9 FOR TABLES IN SCHEMA public;
> DROP PUBLICATION testpub_tbl9;
> "; done | psql -v ON_ERROR_STOP=1 >psql_pub.log || break
> wait
> done
> wait
> grep -A1 'ERROR: cache lookup failed' server.log
>
> It fails for me as below:
> ITERATION 1
> NOTICE: table "testpub_root" does not exist, skipping
> ERROR: cache lookup failed for relation 16880
> 2026-10-12 15:21:47.421 EDT|u2|regression|6acd334b.34270f|ERROR: cache lookup failed for relation 16880
> 2026-10-12 15:21:47.421 EDT|u2|regression|6acd334b.34270f|STATEMENT: CREATE PUBLICATION testpub_tbl9 FOR TABLES IN
> SCHEMA public;
> or
> ...
> ITERATION 2
> ERROR: cache lookup failed for relation 17514
> 2026-10-12 15:21:05.597 EDT|u2|regression|6acd3321.3426de|ERROR: cache lookup failed for relation 17514
> 2026-10-12 15:21:05.597 EDT|u2|regression|6acd3321.3426de|STATEMENT: DROP PUBLICATION testpub_tbl9;
>
> Reproduced starting from 5a2832465 (with slightly different syntax).

Thanks for reporting this Alexander.
This fails because RemovePublicationSchemaById() calls
GetSchemaPublicationRelations(), which collects relation OIDs using a
catalog snapshot. If a relation is dropped concurrently after that
snapshot, its OID can still be present in the returned list.
InvalidatePublicationRels() then calls
CacheInvalidateRelcacheByRelid() for that OID. By this point, the
relation may already have been removed and its invalidation processed,
so the lookup fails with:
cache lookup failed for relation %u

The publishing session does not hold a lock on the relation, so the
concurrent DROP TABLE is not blocked.
I felt InvalidatePublicationRels() should simply skip relations that
no longer exist. There is no relcache entry left to invalidate, and
the DROP has already queued the required invalidation.

Attached a patch to handle the same.

Regards,
Vignesh