Re: [HACKERS] walsender & parallelism - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] walsender & parallelism
Date
Msg-id 20170424180033.ckmabntxh5oze3qm@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] walsender & parallelism  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Responses Re: [HACKERS] walsender & parallelism  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List pgsql-hackers
On 2017-04-24 18:29:51 +0200, Petr Jelinek wrote:
> On 24/04/17 07:42, Andres Freund wrote:
> > 
> > 
> > On April 23, 2017 10:31:18 PM PDT, Petr Jelinek <petr.jelinek@2ndquadrant.com> wrote:
> >> On 24/04/17 04:31, Petr Jelinek wrote:
> >> So actually maybe running regression tests through it might be
> >> reasonable approach if we add new make target for it.
> > 
> > That sounds like a good plan.
> > 
> > 
> >> Note that the first patch is huge. That's because I needed to add
> >> alternative output for largeobject test because it uses fastpath
> >> function calls which are not allowed over replication protocol.
> > 
> > There's no need for that restriction, is there?  At least for db walsenders...
> > 
> 
> No, there is no real need to restring the extended protocol either but
> we do so currently. The point of allowing SQL was to allow logical
> replication to work, not to merge walsender completely into normal
> backend code.

Well, that's understandable, but there's also the competing issue that
we need something that is well defined and behaved.


> Obviously it
> means walsender is still special but as I said, my plan was to make it
> work for logical replication not to merge it completely with existing
> backends.

Yea, and I don't think that's an argument for anything on its own,
sorry.

- Andres



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Interval for launching the table sync worker
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table