Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Sharing more infrastructure between walsenders and regular backends (was Re: Switching timeline over streaming replication)
Date: 2012-10-04 16:00:00
Message-ID: 28424.1349366400@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

			regards, tom lane


In response to

Responses

pgsql-hackers by date

Next:From: Boszormenyi ZoltanDate: 2012-10-04 16:19:36
Subject: Re: [PATCH] Make pg_basebackup configure and start standby [Review]
Previous:From: Tom LaneDate: 2012-10-04 15:43:12
Subject: Re: bison location reporting for potentially-empty list productions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group