Logical replication and synchronous replication

Started by Masahiko Sawadaover 8 years ago3 messages
#1Masahiko Sawada
sawada.mshk@gmail.com

Hi,

As doc of logical decoding said as a note[1]https://www.postgresql.org/docs/devel/static/logicaldecoding-synchronous.html, logical replication can
support the synchronous replication with some restriction. But In
addition to this, IIUC in logical replication decoded data is sent to
subscribers only when the commit WAL record is decoded (calls
ReorderBufferCommit) . It means that the local SQL execution and
applying the decoded data on subscriber side are always executed in a
sequential order, and the response time can simply be doubled or even
more (OTOH a good point is that decoded data of aborted transaction is
never sent to subscriber). I think there will be a lot of peoples who
want to use logical synchronous replication but this is a big
restriction for such user. I think we should document it or deal with
it.
Thought?

[1]: https://www.postgresql.org/docs/devel/static/logicaldecoding-synchronous.html

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#2Craig Ringer
craig@2ndquadrant.com
In reply to: Masahiko Sawada (#1)
Re: Logical replication and synchronous replication

On 18 April 2017 at 18:55, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

Hi,

As doc of logical decoding said as a note[1], logical replication can
support the synchronous replication with some restriction. But In
addition to this, IIUC in logical replication decoded data is sent to
subscribers only when the commit WAL record is decoded (calls
ReorderBufferCommit) .

Correct.

It means that the local SQL execution and
applying the decoded data on subscriber side are always executed in a
sequential order, and the response time can simply be doubled or even
more (OTOH a good point is that decoded data of aborted transaction is
never sent to subscriber). I think there will be a lot of peoples who
want to use logical synchronous replication but this is a big
restriction for such user. I think we should document it or deal with
it.
Thought?

Definitely should be documented. I think it's covered under logical
decoding, but needs at least an xref.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#3Masahiko Sawada
sawada.mshk@gmail.com
In reply to: Craig Ringer (#2)
Re: Logical replication and synchronous replication

On Tue, Apr 18, 2017 at 9:05 PM, Craig Ringer <craig@2ndquadrant.com> wrote:

On 18 April 2017 at 18:55, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

Hi,

As doc of logical decoding said as a note[1], logical replication can
support the synchronous replication with some restriction. But In
addition to this, IIUC in logical replication decoded data is sent to
subscribers only when the commit WAL record is decoded (calls
ReorderBufferCommit) .

Correct.

It means that the local SQL execution and
applying the decoded data on subscriber side are always executed in a
sequential order, and the response time can simply be doubled or even
more (OTOH a good point is that decoded data of aborted transaction is
never sent to subscriber). I think there will be a lot of peoples who
want to use logical synchronous replication but this is a big
restriction for such user. I think we should document it or deal with
it.
Thought?

Definitely should be documented. I think it's covered under logical
decoding, but needs at least an xref.

Yes, I think so too. I'll send a patch for that this week, and maybe
will propose a improvement patch for logical sync replication in the
next release cycle.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers