| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: max_standby_delay considered harmful |
| Date: | 2010-05-03 17:21:08 |
| Message-ID: | AANLkTimNx5bW0eTwcWUe079viqAQ9Sb5O-mdlMiZFb_v@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, May 3, 2010 at 11:37 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-05-03 17:34:32 | Re: Show schema in COPY error CONTEXT strings |
| Previous Message | Stephen Frost | 2010-05-03 17:13:59 | Re: max_standby_delay considered harmful |