Tom Lane <tgl@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
