On 2017-04-26 08:41:46 +0800, Craig Ringer wrote:
> I'd very much like to reduce the amount of magic global juggling done
> by the walsender, unify the XLogRead paths, unify the timeline
> following logic for physical walsenders, logical walsenders and
> logical decoding on normal backends, allow n
On 26 April 2017 at 02:36, Andres Freund wrote:
> 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 conf
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 wrote:
> >> Andres Freund writes:
> >>> I've for a while suspected that the separation & duplication of
> >>> infrastructure between walsenders and normal backe
On Tue, Apr 25, 2017 at 2:24 PM, Petr Jelinek
wrote:
> On 25/04/17 17:13, Fujii Masao wrote:
> > On Tue, Apr 25, 2017 at 11:34 PM, Tom Lane wrote:
> > OTOH, I believe that logical replication is still useful even without
> > initial table sync feature. So reverting the table sync patch seems
> >
On 25/04/17 17:13, Fujii Masao wrote:
> On Tue, Apr 25, 2017 at 11:34 PM, Tom Lane wrote:
>> Andres Freund 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 radi
On 2017-04-25 10:34:20 -0400, Tom Lane wrote:
> Andres Freund 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
On Tue, Apr 25, 2017 at 11:34 PM, Tom Lane wrote:
> Andres Freund 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 que
Andres Freund 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 a
Hi,
I've for a while suspected that the separation & duplication of
infrastructure between walsenders and normal backends isn't nice. But
looking at the code changes in v10 drove that home quite a bit.
The major changes in this area are
1) d1ecd539477fe640455dc890216a7c1561e047b4 - Add a SHOW co
