Re: Sharing more infrastructure between walsenders and regular backends (was Re: Switching timeline over streaming replication)

On 04.10.2012 19:00, Tom Lane wrote:
> Heikki Linnakangas<hlinnakangas(at)vmware(dot)com> writes:
>> So I propose the attached patch. I made small changes to postgres.c to
>> make it call exec_replication_command() instead of exec_simple_query(),
>> and reject extend query protocol, in a WAL sender process. A lot of code
>> related to handling the main command loop and signals is removed from
>> walsender.c.
>
> Why do we need the forbidden_in_wal_sender stuff? If we're going in
> this direction, I suggest there is little reason to restrict what the
> replication client can do. This seems to be both ugly and a drag on
> the performance of normal backends.

Well, there's not much need for parameterized queries or cursors with
the replication command set at the moment. I don't think it's worth it
to try to support them. Fastpath function calls make no sense either, as
you can't call user-defined functions in a walsender anyway.

Perhaps we could make walsenders even more like regular backends than
what I was proposing, so that the replication commands are parsed and
executed just like regular utility commands. However, that'd require
some transaction support in walsender, for starters, which seems messy.
It might become sensible in the future if the replication command set
gets even more complicated, but it doesn't seem like a good idea at the
moment.

- Heikki