* Robert Haas (robertmh...@gmail.com) wrote: > On Mon, May 3, 2010 at 11:37 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > I'm inclined to think that we should throw away all this logic and just > > have the slave cancel competing queries if the replay process waits > > more than max_standby_delay seconds to acquire a lock. > > What if we somehow get into a situation where the replay process is > waiting for a lock over and over and over again, because it keeps > killing conflicting processes but something restarts them and they > take locks over again? It seems hard to ensure that replay will make > adequate progress with any substantially non-zero value of > max_standby_delay under this definition.
That was my first question too- but I reread what Tom wrote and came to
a different conclusion: If the reply process waits more than
max_standby_delay to acquire a lock, then it will kill off *everything*
it runs into from that point forward, until it's done with whatever is
currently available. At that point, the 'timer' would reset back to
zero.
When/how that timer gets reset was a question I had, but I feel like
"until nothing is available" makes sense and is what I assumed Tom was
thinking.
Thanks,
Stephen
signature.asc
Description: Digital signature
