Re: Speedup twophase transactions
От | Jesper Pedersen |
---|---|
Тема | Re: Speedup twophase transactions |
Дата | |
Msg-id | 573F07AE.1010003@redhat.com обсуждение исходный текст |
Ответ на | Re: Speedup twophase transactions (Stas Kelvich <s.kelvich@postgrespro.ru>) |
Ответы |
Re: Speedup twophase transactions
|
Список | pgsql-hackers |
Hi, On 04/13/2016 10:31 AM, Stas Kelvich wrote: >> On 13 Apr 2016, at 01:04, Michael Paquier <michael.paquier@gmail.com> wrote: >> That's too late for 9.6 unfortunately, don't forget to add that in the next CF! > > Fixed patch attached. There already was infrastructure to skip currently > held locks during replay of standby_redo() and I’ve extended that with check for > prepared xids. > > The reason why I’m still active on this thread is because I see real problems > in deploying 9.6 in current state. Let me stress my concern: current state of things > _WILL_BREAK_ async replication in case of substantial load of two phase > transactions on master. And a lot of J2EE apps falls into that category, as they > wrap most of their transactions in prepare/commit. Slave server just will always > increase it lag and will never catch up. It is possible to deal with that by switching > to synchronous replication or inserting triggers with pg_sleep on master, but it > doesn’t looks like normal behaviour of system. > Discussed with Noah off-list I think we should revisit this for 9.6 due to the async replica lag as shown in [1]. The performance improvement for the master node is shown in [2]. As I see it there are 3 options to resolve this (in one way or another) * Leave as is, document the behaviour in release notes/documentation * Apply the patch for slaves * Revert the changes done to the twophase.c during the 9.6 cycle. All have pros/cons for the release. Latest slave patch by Stas is on [3]. Thoughts from others on the matter would be appreciated. [1] http://www.postgresql.org/message-id/E7497864-DE11-4099-83F5-89FB97AF5073@postgrespro.ru [2] http://www.postgresql.org/message-id/5693F703.3000009@redhat.com [3] https://commitfest.postgresql.org/10/523/ Best regards, Jesper
В списке pgsql-hackers по дате отправления: