On Mon, 2010-05-03 at 13:21 -0400, Robert Haas 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 is one argument against, and a reason why just one route is bad. We already have more than one way, so another option is useful -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
