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: | Raw Message | Whole Thread | 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 |