Re: Separation walsender & normal backends

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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Andres Freund <andres(at)anarazel(dot)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