From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | daveg <daveg(at)sonic(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: OperationalError: FATAL: lock AccessShareLock on object 0/1260/0 is already |
Date: | 2011-08-14 04:16:39 |
Message-ID: | CA+TgmobiDb-igYZifaZfLFX15DbpZnLSB4Xp1i8me+_3rRBr2Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
>
> This happens on postgresql 8.4.7 on a large (512GB, 32 core) system that has
> been up for months. It started happening sporadicly a few days ago. It will
> do this for a period of several minutes to an hour and then go back to
> normal for hours or days.
>
> One complete failing session out of several hundred around that time:
> -----------------
> 2011-08-09 00:01:04.446 8823 [unknown] [unknown] LOG: connection received: host=op05.xxx port=34067
> 2011-08-09 00:01:04.446 8823 c77 apps LOG: connection authorized: user=apps database=c77
> 2011-08-09 00:01:04.449 8823 c77 apps 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | daveg | 2011-08-14 05:44:44 | Re: OperationalError: FATAL: lock AccessShareLock on object 0/1260/0 is already |
Previous Message | Robert Haas | 2011-08-14 04:12:19 | Re: vacuum scheduling (was: index-only scans) |