On Sun, Aug 2, 2020 at 2:11 PM Justin Pryzby <pry...@telsasoft.com> wrote: > Based on commit logs, I suspect this may be an "older bug", specifically maybe > with: > > |commit 898e5e3290a72d288923260143930fb32036c00c > |Author: Robert Haas <rh...@postgresql.org> > |Date: Thu Mar 7 11:13:12 2019 -0500 > | > | Allow ATTACH PARTITION with only ShareUpdateExclusiveLock. > > I don't think it matters, but the process surrounding the table being INSERTed > INTO is more than a little special, involving renames, detaches, creation, > re-attaching within a transaction. I think that doesn't matter though, and > the > issue is surrounding the table being SELECTed *from*, which is actually behind > a view.
That's an entirely reasonable guess, but it doesn't seem easy to understand exactly what happened here based on the provided information. The assertion failure probably indicates that pinfo->relid_map[] and partdesc->oids[] differ in some way other than additional elements having been inserted into the latter. For example, some elements might have disappeared, or the order might have changed. This isn't supposed to happen, because DETACH PARTITION requires heavier locking, and the order changing without anything getting detached should be impossible. But evidently it did. If we could dump out the two arrays in question it might shed more light on exactly how things went wrong. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
