On 2020-Aug-27, Robert Haas wrote: > On Wed, Aug 26, 2020 at 7:40 PM Alvaro Herrera <alvhe...@2ndquadrant.com> > wrote: > > To mark it detached means to set pg_inherits.inhdetached=true. That > > column name is a bit of a misnomer, since that column really means "is > > in the process of being detached"; the pg_inherits row goes away > > entirely once the detach process completes. This mark guarantees that > > everyone will see that row because the detaching session waits long > > enough after committing the first transaction and before deleting the > > pg_inherits row, until everyone else has moved on. > > OK. Do you just wait until the XID of the transaction that set > inhdetached is all-visible, or how do you do it?
I'm just doing WaitForLockers( ... AccessExclusiveLock ...) on the partitioned table at the start of the second transaction. That will wait until all lockers that have obtained a partition descriptor with the old definition are gone. Note we don't actually lock the partitioned table with that lock level. In the second transaction we additionally obtain AccessExclusiveLock on the partition itself, but that's after nobody sees it as a partition anymore. That lock level is needed for some of the internal DDL changes, and should not cause problems. I thought about using WaitForOlderSnapshots() instead of waiting for lockers, but it didn't seem to solve any actual problem. Note that on closing the first transaction, the locks on both tables are released. This avoids the deadlock hazards because of the lock upgrades that would otherwise occur. This means that the tables could be dropped or changed in the meantime. The case where either relation is dropped is handled by using try_relation_open() in the second transaction; if either table is gone, then we can just mark the operation as completed. This part is a bit fuzzy. One thing that should probably be done is have a few operations (such as other ALTER TABLE) raise an error when run on a table with inhdetached=true, because that might get things out of step and potentially cause other problems. I've not done that yet. > So all the plans that were created before you set > inhdetached=true have to be guaranteed to be invaliated or gone > altogether before you can actually delete the pg_inherits row. It > seems like it ought to be possible to ensure that, though I am not > surely of the details exactly. Is it sufficient to wait for all > transactions that have locked the table to go away? I'm not sure > exactly how this stuff interacts with the plan cache. Hmm, any cached plan should be released with relcache inval events, per PlanCacheRelCallback(). There are some comments in plancache.h about "unsaved" cached plans that I don't really understand :-( -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
