"John Smith" <[EMAIL PROTECTED]> 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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
