Re: Slow catchup of 2PC (twophase) transactions on replica in LR
От | Heikki Linnakangas |
---|---|
Тема | Re: Slow catchup of 2PC (twophase) transactions on replica in LR |
Дата | |
Msg-id | a375c573-6c9b-4f0f-82c4-eb19cef2a4ca@iki.fi обсуждение исходный текст |
Ответ на | Re: Slow catchup of 2PC (twophase) transactions on replica in LR (Давыдов Виталий <v.davydov@postgrespro.ru>) |
Ответы |
Re: Slow catchup of 2PC (twophase) transactions on replica in LR
|
Список | pgsql-hackers |
On 29/02/2024 19:34, Давыдов Виталий wrote: > Dear All, > > Consider, please, my patch for async commit for twophase transactions. > It can be applicable when catchup performance is not enought with > publication parameter twophase = on. > > The key changes are: > > * Use XLogSetAsyncXactLSN instead of XLogFlush as it is for usual > transactions. > * In case of async commit only, save 2PC state in the pg_twophase file > (but not fsync it) in addition to saving in the WAL. The file is > used as an alternative to storing 2pc state in the memory. > * On recovery, reject pg_twophase files with future xids. > > Probably, 2PC async commit should be enabled by a GUC (not implemented > in the patch). In a nutshell, this changes PREPARE TRANSACTION so that if synchronous_commit is 'off', the PREPARE TRANSACTION is not fsync'd to disk. So if you crash after the PREPARE TRANSACTION has returned, the transaction might be lost. I think that's completely unacceptable. If you're ok to lose the prepared state of twophase transactions on crash, why don't you create the subscription with 'two_phase=off' to begin with? -- Heikki Linnakangas Neon (https://neon.tech)
В списке pgsql-hackers по дате отправления: