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

From houzj.fnst@fujitsu.com
Subject RE: [HACKERS] logical decoding of two-phase transactions
Date
Msg-id OS0PR01MB57164956F553382A6D98578994639@OS0PR01MB5716.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: [HACKERS] logical decoding of two-phase transactions  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [HACKERS] logical decoding of two-phase transactions
List pgsql-hackers
> I have incorporated all your changes and additionally made few more changes
> (a) got rid of LogicalRepBeginPrepareData and instead used
> LogicalRepPreparedTxnData, (b) made a number of changes in comments and
> docs, (c) ran pgindent, (d) modified tests to use standard wait_for_catch
> function and removed few tests to reduce the time and to keep regression
> tests reliable.

Hi,

When reading the code, I found some comments related to the patch here.

                 * XXX Now, this can even lead to a deadlock if the prepare
                 * transaction is waiting to get it logically replicated for
                 * distributed 2PC. Currently, we don't have an in-core
                 * implementation of prepares for distributed 2PC but some
                 * out-of-core logical replication solution can have such an
                 * implementation. They need to inform users to not have locks
                 * on catalog tables in such transactions.
                 */

Since we will have in-core implementation of prepares, should we update the comments here ?

Best regards,
houzj

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: PoC/WIP: Extended statistics on expressions
Next
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: Add Nullif case for eval_const_expressions_mutator