| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin. |
| Date: | 2010-01-23 21:40:40 |
| Message-ID: | 407d949e1001231340n36a2cb9i28cc6693b0f17996@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
On Sat, Jan 23, 2010 at 8:28 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> What is your proposed way of handling buffer pin deadlocks? That will be
> acceptable and working to some extent in the next week?
>
> Wait forever isn't always a good idea, anymore, if it ever was.
I've never said it was always a good idea. But killing correctly
running queries isn't always a good idea either. I'm interested in
using HS for running read-only replicas for load balancing. It would
pretty sad if queries dispatched to a read-only replica received a
spurious unpredictable errors for reasons the application programmer
cannot control.
I'll look at the buffer pin deadlock problem again, but I didn't
realize the situation was so dire. And what were the downsides of the
"stop gap"?
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2010-01-23 21:59:33 | Re: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin. |
| Previous Message | Tom Lane | 2010-01-23 21:29:23 | pgsql: Insert CHECK_FOR_INTERRUPTS calls into loops in dbsize.c, to |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-01-23 21:57:19 | Re: commit fests |
| Previous Message | Tom Lane | 2010-01-23 21:35:52 | Re: We've broken something in error recovery |