Thread: Strange error message
Hi, we've suddenly started getting this error message out of postgres (7.0.2). Does anybody know where it comes from? ERROR: UNLockBuffer: buffer 0 is not locked Any help appreciated, Adriaan
Adriaan Joubert <a.joubert@albourne.com> writes: > we've suddenly started getting this error message out of postgres > (7.0.2). Does anybody know where it comes from? > ERROR: UNLockBuffer: buffer 0 is not locked Evidently something is passing an invalid buffer number to LockBuffer in src/backend/storage/buffer/bufmgr.c. (0 is InvalidBuffer, but LockBuffer won't notice that unless you compiled with asserts enabled.) Whatever the bug is, it's not directly LockBuffer's fault. What exactly are you doing that provokes this message? regards, tom lane
Tom Lane wrote: > Adriaan Joubert <a.joubert@albourne.com> writes: > > we've suddenly started getting this error message out of postgres > > (7.0.2). Does anybody know where it comes from? > > > ERROR: UNLockBuffer: buffer 0 is not locked > > Evidently something is passing an invalid buffer number to LockBuffer > in src/backend/storage/buffer/bufmgr.c. (0 is InvalidBuffer, but > LockBuffer won't notice that unless you compiled with asserts enabled.) > Whatever the bug is, it's not directly LockBuffer's fault. Right, I'vebuilt a new database and everything seemed fine for a while and now I've got this message back. It is due to the index on one of our tables getting messed up - at least, if we drop and recreate the index everything is fine. What should I do to track down what is happening? Compile with asserts, or run with specific logging? Any advice appreciated! Adriaan
Adriaan Joubert <a.joubert@albourne.com> writes: >>>> ERROR: UNLockBuffer: buffer 0 is not locked > Right, I'vebuilt a new database and everything seemed fine for a while and > now I've got this message back. It is due to the index on one of our > tables getting messed up - at least, if we drop and recreate the index > everything is fine. What should I do to track down what is happening? > Compile with asserts, or run with specific logging? Compile with asserts and -g, and get a backtrace from the ensuing coredump. (LockBuffer *will* Assert when passed a zero. If we are really lucky, we might see an earlier Assert failure that will give more clue about where the zero comes from --- but if not, the backtrace from the bogus LockBuffer call might still be useful.) regards, tom lane