Re: logical decoding of two-phase transactions - Mailing list pgsql-hackers

From Andres Freund
Subject Re: logical decoding of two-phase transactions
Date
Msg-id 20170328143840.b7qdvqh3uh74f2oa@alap3.anarazel.de
Whole thread Raw
In response to Re: logical decoding of two-phase transactions  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
On 2017-03-28 15:32:49 +0100, Simon Riggs wrote:
> On 28 March 2017 at 03:53, Craig Ringer <craig@2ndquadrant.com> wrote:
> > On 28 March 2017 at 09:25, Andres Freund <andres@anarazel.de> wrote:
> >
> >> If you actually need separate decoding of 2PC, then you want to wait for
> >> the PREPARE to be replicated.  If that replication has to wait for the
> >> to-be-replicated prepared transaction to commit prepared, and commit
> >> prepare will only happen once replication happened...
> >
> > In other words, the output plugin cannot decode a transaction at
> > PREPARE TRANSACTION time if that xact holds an AccessExclusiveLock on
> > a catalog relation we must be able to read in order to decode the
> > xact.
> 
> Yes, I understand.
> 
> The decoding plugin can choose to enable lock_timeout, or it can
> choose to wait for manual resolution, or it could automatically abort
> such a transaction to avoid needing to decode it.

That doesn't solve the problem. You still left with replication that
can't progress.  I think that's completely unacceptable.  We need a
proper solution to this, not throw our hands up in the air and hope that
it's not going to hurt a whole lot of peopel.


> I don't think its for us to say what the plugin is allowed to do. We
> decided on a plugin architecture, so we have to trust that the plugin
> author resolves the issues. We can document them so those choices are
> clear.

I don't think this is "plugin architecture" related. The output pluging
can't do right here, this has to be solved at a higher level.

- Andres



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: [WIP] RE: DECLARE STATEMENT setting up a connection in ECPG
Next
From: Pavel Stehule
Date:
Subject: Re: New CORRESPONDING clause design