Re: Sharing more infrastructure between walsenders and regular backends (was Re: Switching timeline over streaming replication) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Sharing more infrastructure between walsenders and regular backends (was Re: Switching timeline over streaming replication)
Date
Msg-id 28424.1349366400@sss.pgh.pa.us
Whole thread Raw
In response to Sharing more infrastructure between walsenders and regular backends (was Re: Switching timeline over streaming replication)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: Sharing more infrastructure between walsenders and regular backends (was Re: Switching timeline over streaming replication)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
Heikki Linnakangas <hlinnakangas@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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: bison location reporting for potentially-empty list productions
Next
From: Boszormenyi Zoltan
Date:
Subject: Re: [PATCH] Make pg_basebackup configure and start standby [Review]