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

From Stas Kelvich
Subject Re: [HACKERS] logical decoding of two-phase transactions
Date
Msg-id 25A09FA8-5B0E-447D-97FB-F37F3B0E34E9@postgrespro.ru
Whole thread Raw
In response to Re: [HACKERS] logical decoding of two-phase transactions  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: [HACKERS] logical decoding of two-phase transactions  (Craig Ringer <craig@2ndquadrant.com>)
Re: [HACKERS] logical decoding of two-phase transactions  (Stas Kelvich <s.kelvich@postgrespro.ru>)
List pgsql-hackers
> On 2 Mar 2017, at 11:00, Craig Ringer <craig@2ndquadrant.com> wrote:
>
> We already have it, because we just decoded the PREPARE TRANSACTION.
> I'm preparing a patch revision to demonstrate this.

Yes, we already have it, but if server reboots between commit prepared (all
prepared state is gone) and decoding of this commit prepared then we loose
that mapping, isn’t it?

> BTW, I've been reviewing the patch in more detail. Other than a bunch
> of copy-and-paste that I'm cleaning up, the main issue I've found is
> that in DecodePrepare, you call:
>
>    SnapBuildCommitTxn(ctx->snapshot_builder, buf->origptr, xid,
>                       parsed->nsubxacts, parsed->subxacts);
>
> but I am not convinced it is correct to call it at PREPARE TRANSACTION
> time, only at COMMIT PREPARED time. We want to see the 2pc prepared
> xact's state when decoding it, but there might be later commits that
> cannot yet see that state and shouldn't have it visible in their
> snapshots.

Agree, that is problem. That allows to decode this PREPARE, but after that
it is better to mark this transaction as running in snapshot or perform prepare
decoding with some kind of copied-end-edited snapshot. I’ll have a look at this.

--
Stas Kelvich
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company





pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] patch: function xmltable
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Proposal: Local indexes for partitioned table