Skip site navigation (1) Skip section navigation (2)

Re: Recovery failed on a backup with " lock AccessShareLock on object 16477/244169/0 is already held"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "John Smith" <sodgodofall(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Recovery failed on a backup with " lock AccessShareLock on object 16477/244169/0 is already held"
Date: 2008-06-30 19:26:40
Message-ID: 3602.1214854000@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
"John Smith" <sodgodofall(at)gmail(dot)com> writes:
> 2008-06-17 23:53:53.206 Local time zone must be set--see zic manual
> page PANIC:  failed to re-find shared lock object
> 2008-06-17 23:53:53.207 Local time zone must be set--see zic manual
> page STATEMENT:  commit prepared '148969' ;

> I believe this panic is probably bug #3245 based on the description of
> that bug - http://archives.postgresql.org/pgsql-bugs/2007-04/msg00075.php

Yeah, looks like it to me too.

> At this point I attempted to do a recovery using the continuous
> archive backup on the warm standby system.  Instead of recovering
> correctly it encountered this FATAL error where a AccessSharedLock was
> already held.
> 2008-06-18 00:05:34.298 Local time zone must be set--see zic manual
> page FATAL:  lock AccessShareLock on object 16477/244169/0 is already
> held
> 2008-06-18 00:05:34.299 Local time zone must be set--see zic manual
> page LOG:  startup process (PID 17377) exited with exit code 1
> 2008-06-18 00:05:34.299 Local time zone must be set--see zic manual
> page LOG:  aborting startup due to startup process failure

> Is this FATAL error seen on recovery a different bug or is it just a
> direct result of bug #3245?

It probably is the same bug.  The underlying cause of that bug is
explained here:
http://archives.postgresql.org/pgsql-bugs/2007-04/msg00129.php
I think what you are seeing is just a variant case caused by the same
lock being written out to the twophase file twice.  In any case there's
probably little point in digging further until you've updated to a
version with that fix --- if you still see the problem afterward,
we can look closer.

BTW, what's with the bizarre "Local time zone must be set--see zic
manual" where the timezone should be?  Are you intentionally selecting
the "Factory" zone?

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: John SmithDate: 2008-06-30 22:35:42
Subject: Re: Recovery failed on a backup with " lock AccessShareLock on object 16477/244169/0 is already held"
Previous:From: John SmithDate: 2008-06-30 17:40:03
Subject: Recovery failed on a backup with " lock AccessShareLock on object 16477/244169/0 is already held"

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group