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. > I don't think we want to throttle WAL sending/receiving at all. The WAL > senders should always keep up with the amount of WAL generated. If the > rate of WAL sending is restricted, then the pg_basebackup (or another > client application) might never catch up. Yes, and this is exactly why restricting *generation* is needed. > Also, IMO, pg_basebackup starts at the current WAL segment. Thus the > unthrottled WAL transfer shouldn't cause significant additional load, > such as reading many old WAL segments from the master's disk. The possible extra load happens if the *network* not because of disk. Think of replication over - possibly slow - WAN.
Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
