On 2021-Nov-11, Tom Lane wrote: > It appears to me that commit 71f4c8c6f (DETACH PARTITION CONCURRENTLY) > broke the semantics here, because now things work differently with a > partitioned PK table than with a plain table, thanks to not bothering > to distinguish questions of how to handle partition detachment from > questions of visibility of individual data tuples. We evidently > haven't got test coverage for this :-(, which is perhaps not so > surprising because all this behavior long predates the isolationtester > infrastructure that would've allowed us to test it mechanically. > > Anyway, I think that (1) we should write some more test cases around > this behavior, (2) you need to establish the snapshot to use in two > different ways for the RI_FKey_check and ri_Check_Pk_Match cases, > and (3) something's going to have to be done to repair the behavior > in v14 (unless we want to back-patch this into v14, which seems a > bit scary).
I think we (I) should definitely pursue fixing whatever was broken by DETACH CONCURRENTLY, back to pg14, independently of this patch ... but I would appreciate some insight into what the problem is. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ "Find a bug in a program, and fix it, and the program will work today. Show the program how to find and fix a bug, and the program will work forever" (Oliver Silfridge)
