On Mon, Mar 28, 2011 at 1:51 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote:
>>> The 'apply' mode would be quite interesting, it would make it easier to >>> build load-balancing clusters. But the patch isn't up to the task on that >>> yet - the 'apply' status report is only sent after >>> wal_receiver_status_interval fills up, so you get long delays. >> >> Yes it's up to the task, you misread it. It will continue sending >> replies while apply<> flush and then it will fall back to the >> behaviour you mention. > > There's nothing to wake up the walreceiver after applying a commit record. > > Oh, you're relying on the periodic wakeups specified by NAPTIME_PER_CYCLE > (100ms). That's still on average a 50ms delay to every commit. Rubbish. "Every commit", no way. How could you think that? That delay affects only the last commit of a sequence of commits after which the server goes quiet. And that only applies to people that have specifically chosen to wait for the apply, which as you say means they may have fairly long waits anyway. > We should try > to eliminate these polling loops, not make them more important. In fact, we > should raise NAPTIME_PER_CYCLE to, say, 1000ms, to reduce spurious wakeups > on an idle system. I'm OK with changing the polling loops. Is there a big problem there? I think it would take you about an hour to rewrite that, if you wanted to do so. But its not a necessary step to do that, especially when we're discussing whether Latches are actually as portable as we think. That sounds like more risk for a slight gain in performance. > Am I reading the patch correctly that if the standby hasn't applied all WAL > yet, you send a reply message at every wakeup, whether or not any progress > has been made since last time? So if you have a long-running-transaction in > the standby, for example, conflicting with WAL recovery, the standby will > keep sending a status report to the master every 100ms. Sure. First, is that a problem? Why? The WalReceiver isn't busy doing anything else at that point, by definition. The WalSender isn't doing anything then either, by definition. Both are used to higher send rates. Second, if that really is a problem, sounds like a simple "if" test added to reply code. Third, the conflict issues are much reduced as well in this release. For this exact purpose. So I don't see any blockers in what you say. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
