On Tue, Jul 20, 2021 at 5:41 PM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
> I think the crucial aspect of this that needs discussion/feedback the
> most is the transactional vs. non-transactional behavior. All the other
> questions are less important / cosmetic.
Yeah, it seems really tricky to me to get this right. The hard part
is, I think, mostly figuring out what the right behavior really is.
DDL in PostgreSQL is transactional. Non-DDL operations on sequences
are non-transactional. If a given transaction does only one of those
things, it seems clear enough what to do, but when the same
(sub)transaction does both, it gets messy. I'd be tempted to think
about something like:
1. When a transaction performs only non-transactional operations on
sequences, they are emitted immediately.
2. If a transaction performs transactional operations on sequences,
the decoded operations acquire a dependency on the transaction and
cannot be emitted until that transaction is fully decoded. When commit
or abort of that XID is reached, emit the postponed non-transactional
operations at that point.
I think this is similar to what you've designed, but I'm not sure that
it's exactly equivalent. I think in particular that it may be better
to insist that all of these operations are non-transactional and that
the debate is only about when they can be sent, rather than trying to
sort of convert them into an equivalent series of transactional
operations. That approach seems confusing especially in the case where
some (sub)transactions abort.
But this is just my $0.02.
--
Robert Haas
EDB: http://www.enterprisedb.com
