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@2ndquadrant.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.
> I'm not happy that it waits, nor that the wait is non-tunable. I would
> like to see a new parameter added for this.
I wanted to keep it simple for users, but feel free to add a parameter
if you feel it must be configurable.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
