Re: Re: [COMMITTERS] pgsql: Check compulsory parameters in recovery.conf in standby_mode, per

On Tue, 2010-04-06 at 12:38 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Tue, 2010-04-06 at 10:19 +0300, Heikki Linnakangas wrote:
> >> Fujii Masao wrote:
> >>> On Tue, Apr 6, 2010 at 3:29 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> >>>> I was also surprised to note that the Startup process is not signaled by
> >>>> WALReceiver when new WAL is received, so it will continue sleeping even
> >>>> though it has work to do.
> >>> I don't think this is so useful in 9.0 since synchronous replication
> >>> (i.e., transaction commit wait for WAL to be replayed by the standby)
> >>> is not supported.
> >> Well, it would still be useful, as it would shorten the delay. But yeah,
> >> there's a delay in asynchronous replication anyway, so we decided to
> >> keep it simple and just poll. It's not ideal and definitely needs to be
> >> revisited for synchronous mode in the future. Same for walsenders.
> >
> > A signal seems fairly straightforward to me, the archiver did this in
> > 8.0 and it was not considered complex then. Quite why it would be
> > complex here is not clear.
>
> The other side of the problem is that walsender polls too. Eliminating
> the delay from walreceiver doesn't buy you much unless you eliminate the
> delay from the walsender too. And things get complicated there. Do you
> signal the walsenders at every commit? That would be a lot of volume,
> and adds more work for every normal transaction in the primary. Maybe
> not much, but it would be one more thing to worry about and test.

You are trying to connect two unrelated things.

We can argue that the WALSender's delay allows it to build up a good
sized batch of work to transfer.

Having the Startup process wait does not buy us anything at all.
Currently if the Startup process finishes more quickly than the
WALreceiver it will wait for 100ms.

I am surprised at your arguments for simplicity. With Hot Standby you
have insisted that everything should be in place. With SR you seem to
have just stopped at a barely working, poorly documented implementation.
We both know you can fix these things easily and quickly. Please do so.
Not because I say so, but because everybody else will soon notice that
you could have and did not.

--
Simon Riggs www.2ndQuadrant.com