On 04.10.2012 19:00, Tom Lane wrote:
Heikki Linnakangas<hlinnakan...@vmware.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
