Hi Vignesh,
> 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
To confirm, publication_add_schema()->GetSchemaPublicationRelations() gathers
the
oid of relations without acquiring the lock. Therefore another process can drop
the relation and this can cause the cache lookup failure, right?
> 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.
I checked your source, but isn't there still a whole that failure can happen?
Relation can be dropped after the SearchSysCache1().
How about the below? It tries to open the relation, and skip if cannot.
Relation cache can be invalidated via CacheInvalidateRelcache() instead of
...ByTuple().
```
if (list_length(relids) < MAX_RELCACHE_INVAL_MSGS)
{
foreach_oid(relid, relids)
{
Relation rel = try_table_open(relid, AccessShareLock);
if (rel == NULL)
continue;
CacheInvalidateRelcache(rel);
table_close(rel, AccessShareLock);
}
}
```
Best regards,
Hayato Kuroda
FUJITSU LIMITED
