Re: Speedup twophase transactions

From: Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>
To: Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: Speedup twophase transactions
Date: 2016-05-20 12:48:46
Message-ID: 573F07AE.1010003@redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 04/13/2016 10:31 AM, Stas Kelvich wrote:
>> On 13 Apr 2016, at 01:04, Michael Paquier <michael(dot)paquier(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Golub 2016-05-20 13:34:36 Re: Refactor pg_dump as a library?
Previous Message David Rowley 2016-05-20 12:12:24 Re: It's seems that the function "do_text_output_multiline" does not suit for format "line1\nline2\n...lineN".