Re: walsender & parallelism

On 24/04/17 07:42, Andres Freund wrote:
>
>
> On April 23, 2017 10:31:18 PM PDT, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)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. And I don't know about differences well enough to go for
the full merge, especially not at this stage of PG10 dev.

>> As part of this I realized that the parser fallback that I wrote
>> originally for handling SQL in walsender is not robust enough as the
>> lexer would fail on some valid SQL statements. So there is also second
>> patch that does this using different approach which allows any SQL
>> statement.
>
> Haven't looked at the new thing yet, but I'm not particularly surprised... Wonder of there's a good way to fully integrate both grammars, without exploding keywords.
>

I think we'd need to keyword the first word of every replication command
if we wanted to merge both grammar files together. I am not sure if
there is all that much need for that, the pass-through for everything
that is not replication command seems to work just fine. 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.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services