<p dir="ltr"><br /> On 8 Sep. 2016 1:38 pm, "Andres Freund" <<a
href="mailto:andres@anarazel.de">andres@anarazel.de</a>>wrote:<br /> ><br /> > I kind of dislike this approach
fora different reason than already<br /> > mentioned in this thread: Namely it's not re-usable for implementing<br
/>> streaming logical replication of large transaction, i.e. allow to decode<br /> > & apply un-committed
changes. The issue there is that one really needs<br /> > to have multiple transactions active in the same
connection,which this<br /> > approach does not allow.<p dir="ltr">I've been thinking about this recently with an
eyeto handling the majority of transactions on a typical system that neither perform DDL nor are concurrent with it.<p
dir="ltr">Thefollowing might be fairly nonsensical if I've misunderstood the problem as I've not had a chance to more
thanglance at it, but:<p dir="ltr">I wonder if some kind of speculative concurrent decoding+output is possible without
beingable to have multiple xacts on a backend. We could use a shared xact and snapshot for all concurrent xacts. If any
ofthem do anything that requires invalidations etc we dump the speculatively processed ones and fall back to reorder
bufferingand serial output at commit time until we pass the xact that caused an invalidation and don't have more
pending.Add a callback to the output plugin to tell it that speculative decoding of an xact has been aborted.<p
dir="ltr">Ormaybe even just put that speculstive decoding on hold and pick up where we left off partway through the
reorderbuffer when we get around to processing it serially. That way we don't have to discard work already done. More
usefullywe could avoid having to enqueue stuff into the reorder buffer just in case we have to switch to fallback
serialdecoding.<p dir="ltr">Failing that:<p dir="ltr">Since logical decoding only needs read only xacts that roll back,
itonly needs multiple backend private virtualxacts. They don't need SERIALIZABLE/SSI which I think (?) means other
backendsdon't need to be able to wait on them. That seems simpler than what autonomous xacts would need since there we
needthem exposed in PgXact, waitable-on for txid locks, etc. Right? In the same way that historical snapshots are
cut-downmaybe logical decoding xacts can be too.<p dir="ltr">I suspect that waiting for full in-process multiple xact
supportto do interleaved decoding/replay will mean a long wait indeed.
