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. > 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. > PS. you're missing some break's in the switch-statement in > SyncRepWaitForLSN(), effectively making the patch do nothing. OK, thanks. -- 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