On 6/5/18 07:02, Amit Khandekar wrote: > I haven't written a patch for it, but I think we should have a > separate on_commit_stop_workers for eachyou get subtransaction. At > subtransaction commit, we replace the on_commit_stop_workers list of > the parent subtransaction with the one from the committed > subtransaction; and on abort, discard the list of the current > subtransaction. So have a stack of the lists.
Is there maybe a more general mechanism we could attach this to? Maybe resource owners? > Subscription mysub is set to synchronise tables tx1 and tx2 : > CREATE SUBSCRIPTION mysub ... PUBLICATION pubx; > > Now suppose the subscription is altered to synchronise ty1 and ty2, > and then again altered back to synchronise tx1 and tx2 in the same > transaction. > begin; > ALTER SUBSCRIPTION mysub set publication puby; > ALTER SUBSCRIPTION mysub set publication pubx; > commit; > > Here, workers for tx1 and tx2 are added to on_commit_stop_workers > after the publication is set to puby. And then workers for ty1 and ty2 > are further added to that list after the 2nd ALTER command where > publication is set to pubx, because the earlier ALTER command has > already changed the catalogs to denote that ty1 and ty2 are being > synchronised. Effectively, at commit, all the workers are targetted to > be stopped, when actually at commit time there is no final change in > the tables to be synchronised. I'm not so bothered about this scenario. When you drop and then recreate a table in the same transaction, that doesn't mean you keep the data that was previously in the table. If you want to *undo* a change, you need to do rollback, not commit further changes that try to recreate the previous state. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services