From: Petr Jelinek <petr.jelinek@2ndquadrant.com>
To: Arseny Sher <a.sher@postgrespro.ru>
To: Nikhil Sontakke <nikhils@2ndquadrant.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: David Steele <david@pgmasters.net>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Craig Ringer <craig@2ndquadrant.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Sokolov Yura <y.sokolov@postgrespro.ru>
Cc: Stas Kelvich <s.kelvich@postgrespro.ru>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] logical decoding of two-phase transactions
Date: Fri, 25 Jan 2019 15:26:55 +0100
Message-ID: <2e1cdeb7-6940-8558-910a-9673b507bacb@2ndquadrant.com> (raw)
In-Reply-To: <87a7k2996m.fsf@ars-thinkpad>
References: <20180719194208.j5m7qhdmqp46d6yg@alap3.anarazel.de>
<20180720145836.gxwhbftuoyx5h4gc@alap3.anarazel.de>
<CAMGcDxebtC_ZO6EtLA1MgJ6sWbud3Fjtq9HsBwxxhYfoHJdANw@mail.gmail.com>
<20180723135009.w25re6qxbb7njrbd@alap3.anarazel.de>
<CAMGcDxdJNZVq1mX9dZbwEniigi=af8H5dt62C+q2UHwsE+BTaw@mail.gmail.com>
<20180723141435.ercxxh3bj2uc2mjm@alap3.anarazel.de>
<3B37B16B-A473-4352-ABCF-F23AE314D4F7@2ndquadrant.com>
<CAMGcDxeBcMBF0KZ9qMpcb07uX6uLNO5hk=VWCQC514oZuofLmw@mail.gmail.com>
<20180726200241.aje4dv4jsv25v4k2@alap3.anarazel.de>
<CAMGcDxfVBiBXt4F7v58_DfqFD9xnmU8hBEiyqoypon6Ftroe_Q@mail.gmail.com>
<a5ba1686-bb79-f2c3-568d-993e4c53b920@2ndquadrant.com>
<CAMGcDxfWORpkaOaNhFwS4839R_w4wtDgnB8Wj2TmAQXnV78HsQ@mail.gmail.com>
<CAMGcDxe276HwzQ1ErqMHKPf=KTvdSGgu3jYaR+j3-368+amZSA@mail.gmail.com>
<2ba9c978-ede8-35bf-14ec-45570bf0f6aa@2ndquadrant.com>
<87h8fbxjxw.fsf@ars-thinkpad>
<CAMGcDxfnkjtB0MaLRp6wdGoTbGr20yq=dwGf5V26guKBNCtacg@mail.gmail.com>
<87a7k2996m.fsf@ars-thinkpad>
On 14/01/2019 23:16, Arseny Sher wrote:
>
> Nikhil Sontakke <nikhils@2ndquadrant.com> writes:
>
>> I'd like to believe that the latest patch set tries to address some
>> (if not all) of your concerns. Can you please take a look and let me
>> know?
>
> Hi, sure.
>
> General things:
>
> - Earlier I said that there is no point of sending COMMIT PREPARED if
> decoding snapshot became consistent after PREPARE, i.e. PREPARE hadn't
> been sent. I realized since then that such use cases actually exist:
> prepare might be copied to the replica by e.g. basebackup or something
> else earlier.
Basebackup does not copy slots though and slot should not reach
consistency until all prepared transactions are committed no?
>
> - BTW, ReorderBufferProcessXid at PREPARE should be always called
> anyway, because otherwise if xact is empty, we will not prepare it
> (and call cb), even if the output plugin asked us not to filter it
> out. However, we will call commit_prepared cb, which is inconsistent.
>
> - I find it weird that in DecodePrepare and in DecodeCommit you always
> ask the plugin whether to filter an xact, given that sometimes you
> know beforehand that you are not going to replay it: it might have
> already been replayed, might have wrong dbid, origin, etc. One
> consequence of this: imagine that notorious xact with PREPARE before
> point where snapshot became consistent and COMMIT PREPARED after that
> point. Even if filter_cb says 'I want 2PC on this xact', with current
> code it won't be replayed on PREPARE and rbxid will be destroyed with
> ReorderBufferForget. Now this xact is lost.
Yeah this is wrong.
>
> Second patch:
>
> + /* filter_prepare is optional, but requires two-phase decoding */
> + if ((ctx->callbacks.filter_prepare_cb != NULL) && (!opt->enable_twophase))
> + ereport(ERROR,
> + (errmsg("Output plugin does not support two-phase decoding, but "
> + "registered filter_prepared callback.")));
>
> I actually think that enable_twophase output plugin option is
> redundant. If plugin author wants 2PC, he just provides
> filter_prepare_cb callback and potentially others.
+1
> I also don't see much
> value in checking that exactly 0 or 3 callbacks were registred.
>
I think that check makes sense, if you support 2pc you need to register
all callbacks.
>
> Nitpicking:
>
> First patch: I still don't think that these flags need a bitmask.
Since we are discussing this, I personally prefer the bitmask here.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: petr.jelinek@2ndquadrant.com, a.sher@postgrespro.ru, nikhils@2ndquadrant.com, tomas.vondra@2ndquadrant.com, andres@anarazel.de, robertmhaas@gmail.com, david@pgmasters.net, andrew.dunstan@2ndquadrant.com, simon@2ndquadrant.com, craig@2ndquadrant.com, peter.eisentraut@2ndquadrant.com, y.sokolov@postgrespro.ru, s.kelvich@postgrespro.ru, 9erthalion6@gmail.com, tgl@sss.pgh.pa.us, sawada.mshk@gmail.com
Subject: Re: [HACKERS] logical decoding of two-phase transactions
In-Reply-To: <2e1cdeb7-6940-8558-910a-9673b507bacb@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox