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

From Andres Freund
Subject Re: [HACKERS] Separation walsender & normal backends
Date
Msg-id 20170425183604.jnq3tu726gpcx3nt@alap3.anarazel.de
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
List pgsql-hackers
On 2017-04-25 10:34:20 -0400, Tom Lane 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 don't think that's the right solution, I think it's evidence that the
split was a bad idea in the first place.  There's a growing amount of
duplication between the protocols, and a growing number of use-cases
that need facilities of both protocols.  We e.g. now already have SHOW
statements in both, except that they behave slightly differently.  For
logical rep we'd alternatively add more complexity because we'd need
both replication and non-replication connections (to stream changes, to
copy tables, to query config), which'd also complicate administration
because users & hba config have to be setup so the same user can connect
over both.

Therefore I think it's the implementation that's not perfect, but the
idea is perfectly sound.  Having two awkwardly & increasingly different
languages in postgres doesn't sound like a sound idea.

- Andres



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] scram and \password
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] subscription worker doesn't start immediately on eabled