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