From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: logical decoding of two-phase transactions |
Date: | 2017-02-04 00:08:02 |
Message-ID: | 20170204000802.5s527mzrxirevljs@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-02-03 18:47:23 -0500, Robert Haas wrote:
> On Fri, Feb 3, 2017 at 6:00 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > I still haven't seen a credible model for being able to apply a stream
> > of interleaved transactions that can roll back individually; I think we
> > really need the ability to have multiple transactions alive in one
> > backend for that.
>
> Hmm, yeah, that's a problem. That smells like autonomous transactions.
Unfortunately the last few proposals, like spawning backends, to deal
with autonomous xacts aren't really suitable for replication, unless you
only have very large ones. And it really needs to be an implementation
where ATs can freely be switched inbetween. On the other hand, a good
deal of problems (like locking) shouldn't be an issue, since there's
obviously a possible execution schedule.
I suspect this'd need some low-level implemention close to xact.c that'd
allow switching between transactions.
- Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-02-04 00:09:43 | Re: logical decoding of two-phase transactions |
Previous Message | Robert Haas | 2017-02-04 00:07:44 | Re: Redundant comment in ExecutePlan |