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

Thanks for the quick reply Tom. I'll be updating my PG version to one
with a fix for bug #3245 so hopefully we won't see this anymore.

> 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?

I don't think I've put the correct timezone file in /etc/localtime so
it is using some default file from the Gentoo install.

John

On Mon, Jun 30, 2008 at 12:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "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
>