Tom Lane <t...@sss.pgh.pa.us> writes: > Uh, if the slave is overloaded, *any* implementation will be playing > catchup all the time. Not sure about your point here.
Well, sorry, I missed the part where the catchup is measured on walsender side of things. Now that means that a non interrupted flow of queries quicker than the wal sender delay (100ms, right?) on the slave would certainly leave enough room for it to stay current. Well that depends also on the time it takes to replay the wals. I'm trying to decide if exposing this 100ms magic setup (or something else) would allow for a lot more control with respect to what means being overloaded. Say you set the 100ms delay to any value that you know (from testing and log_min_duration_statement, say) just a little higher than the slowest query you typically run on the slave. If that reduces the chances to ever playing cathing-up (as soon as there's no unexpected slow query there), that would be great. If you can manage to make sense of this, I'm interested into hearing how far it is from reality. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
