Hi Vignesh, > Thanks for reporting this issue, I was able to reproduce this. It was > reachable because for a partitioned table OpenTableList() does not > lock the partitions (only a non-partitioned inheritance parent gets > find_all_inheritors() with ShareUpdateExclusiveLock), so ADD TABLE > holds a lock on the root only. The partitions are collected later in > GetPubPartitionOptionRelations() with find_all_inheritors(NoLock). > Dropping a partition takes AccessExclusiveLock on the partition and on > its direct parent, so a direct child conflicts with the ALTER through > the root, but a grandchild does not. > The updated v3 version patch has the changes to handle the same.
While investigating this issue, I found another case where a cache lookup can
fail. Unlike the previously discussed case, this failure occurs while
find_all_inheritors() is still building the relation list, before
InvalidatePublicationRels() is called. Do you think we should also fix,
or should be done in other places?
The issue can be reproduced with a multi-level partition tree [1]. Note that p1
must be created before p2. Brief steps:
0. Run "ALTER PUBLICATION ADD TABLE root".
1. find_all_inheritors(root, NoLock, ...) adds root to rels_list.
2. It processes "root" and appends "p1" and "p2" to rels_list.
3. It processes "p1" and appends "trigger".
4. It processes "p2" and appends "victim".
5. Another backend drops "victim". This cannot be conflicted because the DROP
command
acquires locks only for the table (victim) and its direct parent (p2).
6. The first backend processes "trigger". Invalidation messages can be handled
here because the table has a child and system catalog is opened.
7. It processes "victim". Since it's dropped and the inval message is handled,
it causes the cache lookup failure.
[1]
root
|---- p1
| +---- trigger
| +---- other
+---- p2
+---- victim
Best regards,
Hayato Kuroda
FUJITSU LIMITED
v1-nocfbot-0001-Reproduce-the-cache-lookup-failure.patch
Description: v1-nocfbot-0001-Reproduce-the-cache-lookup-failure.patch
