On Tue, Jul 20, 2021 at 5:41 PM Tomas Vondra <tomas.von...@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
