On 2017-04-25 23:24:40 +0200, Petr Jelinek wrote:
> On 25/04/17 17:13, Fujii Masao wrote:
> > 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.
> >
>
> I don't think that's good idea, the usefulness if much lower without the
> initial copy.
Agreed. I think that'd move us way backwards, and we'd have to tackle
exactly the same issue in a few weeks again.
> The original patch for this added new commands to
> replication protocol, adding generic SQL interface was result of request
> in the reviews.
Yea, I still think it's the right approach in general - I don't think
the patch itself was properly discussed and such though, being
essentially burried in another commit.
> I personally don't mind moving back my original idea of special commands
> if that was the consensus, but previous consensus was to do SQL instead.
I really don't think that'll solve anything.
- Andres
