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
|
Список | 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 по дате отправления: