Re: OperationalError: FATAL: lock AccessShareLock on object 0/1260/0 is already

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

In response to

Browse pgsql-hackers by date

  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