Re: [HACKERS] Separation walsender & normal backends - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: [HACKERS] Separation walsender & normal backends
Date
Msg-id CAHGQGwGiH_2kDqxGUBmZoRMQ3Eu+XEtTmgPYCQVJC55XiYA=tA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Separation walsender & normal backends  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Separation walsender & normal backends  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List pgsql-hackers
On Tue, Apr 25, 2017 at 11:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@anarazel.de> writes:
>> I've for a while suspected that the separation & duplication of
>> infrastructure between walsenders and normal backends isn't nice.
>
> I think we should consider a more radical solution: trying to put
> general SQL query capability into the replication protocol was a
> bad idea and we should revert it while we still can.  The uglinesses
> you mention aren't merely implementation issues, they're an indication
> that that concept is broken in itself.

I think that it's worth considering this option in order to "stabilize"
logical replication stuff before the release. The table sync patch
(which allows walsender to run normal queries) introduced such
uglinesses and increased the complexity in logical rep code.
OTOH, I believe that logical replication is still useful even without
initial table sync feature. So reverting the table sync patch seems
possible idea.

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: [HACKERS] Cached plans and statement generalization
Next
From: Dmitriy Sarafannikov
Date:
Subject: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range