On 08/26/2013 08:15 PM, Hannu Krosing wrote: > On 08/26/2013 12:50 PM, Antonin Houska wrote: >> > On 08/22/2013 03:33 PM, Craig Ringer wrote: >>> >> On 08/22/2013 01:39 PM, PostgreSQL - Hans-Jürgen Schönig wrote: >>> >> >>>> >>> what would be a reasonable scenario where limiting streaming would >>>> >>> make sense? i cannot think of any to be honest. >>> >> I tend to agree. If anything we're likely to want the reverse - the >>> >> ability to throttle WAL *generation* on the master so streaming can keep >>> >> up. >> > (I assume you mean WAL *sending* rather than *generation*.) > I think he meant *generation*, that is making sure that no more > than X amount of WAL is generated in Y amount of time, thereby > making sure that you can stream less WAL without falling behind. >
Exactly so. Sometimes one doesn't want the latency of synchronous replication, but still wants to set a limit on how far behind the standby can fall. It might be for limiting data loss, for making sure a replica can keep up sustainably, or just to make sure the replica never gets far enough behind that the master discards WAL that it still requires. For many people the idea of the replica(s) affecting the master is horrifying. For others, missing a single transaction on a crash is unthinkable. We handle both those pretty well, but the middle ground is currently very hard to walk, and I think that's actually where many people will want to be. I'd certainly rather throttle the master (and send a loud, angry alert to the admin via icinga/nagios) than have a replica fall too far behind and need to be re-inited from scratch. -- Craig Ringer 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
