On 28.03.2011 15:34, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 12:05 PM, Heikki Linnakangas
<heikki.linnakan...@enterprisedb.com> wrote:
On 28.03.2011 13:14, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 10:52 AM, Simon Riggs<si...@2ndquadrant.com>
wrote:
You have no basis on which to prevent this.
It's also already on the Open Items list, put there by you.
Why is this even a discussion point?
FWIW, I agree this is an additional feature that we shouldn't be messing
with at this point in the release cycle.
There is an open item about what the UI is for sync commit/sync rep,
which is the subject of this patch.
plus new functionality. For the UI part, you just need to change GUCs.
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. 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.
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
