* Aidan Van Dyk (aidan@highrise.ca) wrote:
> * Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> [100510 06:03]:
> > A problem with using the name "max_standby_delay" for Tom's suggestion
> > is that it sounds like a hard limit, which it isn't. But if we name it
> > something like:
>
> I'ld still rather an "if your killing something, make sure you kill
> enough to get all the way current" behaviour, but that's just me....
I agree with that comment, and it's more like what max_standby_delay
was. That's what I had thought Tom was proposing initially,
since it makes a heck of alot more sense to me than "just keep
waiting, just keep waiting..".
Now, if it's possible to have things queue up behind the recovery
process, such that the recovery process will only wait up to
timeout * # of locks held when recovery started, that might be alright,
but that's not the impression I've gotten about how this will work.
Of course, I also want to be able to have a Nagios hook that checks how
far behind the slave has gotten, and a way to tell the slave "oook,
you're too far behind, just forcibly catch up right *now*". If I could
use reload to change max_standby_delay (or whatever) and I can figure
out how long the delay is (even if I have to update a table on the
master and then see what it says on the slave..), I'd be happy.
That being said, I do think it makes more sense to wait until we've got
a conflict to start the timer, and I rather like avoiding the
uncertainty of time sync between master and slave by using WAL arrival
time on the slave.
Thanks,
Stephen
