RE: [HACKERS] logical decoding of two-phase transactions

Поиск
Список
Период
Сортировка
От houzj.fnst@fujitsu.com
Тема RE: [HACKERS] logical decoding of two-phase transactions
Дата
Msg-id OS0PR01MB57164956F553382A6D98578994639@OS0PR01MB5716.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: [HACKERS] logical decoding of two-phase transactions  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: [HACKERS] logical decoding of two-phase transactions  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: PoC/WIP: Extended statistics on expressions
Следующее
От: "houzj.fnst@fujitsu.com"
Дата:
Сообщение: RE: Add Nullif case for eval_const_expressions_mutator