| From: | daveg <daveg(at)sonic(dot)net> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: OperationalError: FATAL: lock AccessShareLock on object 0/1260/0 is already |
| Date: | 2011-08-23 07:24:47 |
| Message-ID: | 20110823072447.GE3363@sonic.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Aug 14, 2011 at 12:16:39AM -0400, Robert Haas wrote:
> On Fri, Aug 12, 2011 at 7:19 PM, daveg <daveg(at)sonic(dot)net> wrote:
> > This seems to be bug month for my client. Now there are seeing periods
> > where all new connections fail immediately with the error:
> >
> > FATAL: lock AccessShareLock on object 0/1260/0 is already held
...
> > What can I do to help track this down?
>
> I've seen that error (though not that exact fact pattern) caused by
> bad RAM. It's unclear to me what else could cause it.
>
> In terms of debugging, it seems like it might be sensible to start by
> injecting some debugging code that dumps out the contents of the LOCK
> and LOCALLOCK structures at the point the error occurs.
I've made up the attached patch to print this, please suggest any additions.
I'll deploy this on a couple of the production hosts that have had the
issue this evening, but there is no telling when or if it will strike next.
-dg
--
David Gould daveg(at)sonic(dot)net 510 536 1443 510 282 0869
If simplicity worked, the world would be overrun with insects.
| Attachment | Content-Type | Size |
|---|---|---|
| lock_already_held_print.patch | text/plain | 5.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2011-08-23 11:30:19 | VIP: plpgsql - early embedded sql plan preparation |
| Previous Message | Heikki Linnakangas | 2011-08-23 07:03:55 | Buffering GiST leaf pages too |