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: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 18:28:34
Message-ID: CA+U5nMKwgO0ZfrCxwgxP1pSTE=zpmnLT2vNEg7UXaYqVHLA5qg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 4 October 2012 17:23, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> wrote:
> 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.

It's come up a few times now that people want to run a few queries
either before or after running a base backup.

Since the pg_basebackup stuff uses walsender, this make such things impossible.

So to support that, we need to allow two kinds of connection, one to
"replication" and one to something else, and since the something else
is not guaranteed to exist that makes it even harder.

Andres suggested to me the other day we make walsender more like
regular backends. At the time I wasn't sure I agreed, but reading this
it looks like a sensible way to go.

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


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-10-04 20:58:53
Subject: Re: Sharing more infrastructure between walsenders and regular backends (was Re: Switching timeline over streaming replication)
Previous:From: Fujii MasaoDate: 2012-10-04 17:07:18
Subject: Re: Promoting a standby during base backup (was Re: Switching timeline over streaming replication)

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