From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: AtEOXact_ApplyLauncher() and subtransactions |
Date: | 2018-06-15 04:16:09 |
Message-ID: | e8152719-e4b7-6656-d643-de59b43a6bcc@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2018-06-15 04:21:07 | Re: automating perl compile time checking |
Previous Message | Amit Kapila | 2018-06-15 04:16:05 | Re: Few cosmetic suggestions for commit 16828d5c (Fast Alter Table Add Column...) |