We have another production database,
which is similar with this one.
It has never had REINDEX block problem yet.
One difference between these two databases
is the one having REINDEX problem is using
NTFS file system.
Is it possible the root of problem?
Thanks,
--- Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Litao Wu <litaowu@yahoo.com> writes:
> > (gdb) bt
> > #0 0x420e8bb2 in semop () from
> /lib/i686/libc.so.6
> > #1 0x080ffa28 in PGSemaphoreLock ()
> > #2 0x08116432 in LWLockAcquire ()
> > #3 0x0810f572 in LockBuffer ()
> > #4 0x0807dea3 in _bt_getbuf ()
> > #5 0x080813ec in _bt_leafbuild ()
> > #6 0x080816a6 in _bt_leafbuild ()
> > #7 0x08081b8b in _bt_leafbuild ()
> > #8 0x080813cc in _bt_leafbuild ()
> > #9 0x0807e1d0 in btbuild ()
> > #10 0x081631c3 in OidFunctionCall3 ()
> > #11 0x080920a7 in index_build ()
> > #12 0x08092593 in reindex_index ()
>
> Hmm. I don't think I believe this backtrace. It's
> obviously wrong at
> lines 5-7 - _bt_leafbuild doesn't call itself nor
> call _bt_getbuf.
> It's possible that you don't have any local symbols
> in this executable
> and what we're seeing is the nearest global symbol,
> so let's ignore
> that; but if we take lines 0-4 at face value, what
> it says is that the
> REINDEX is stuck waiting for buffer lock on a buffer
> for a new empty
> page it has just added to the new index. This is
> flatly impossible.
> There is no other process that could possibly be
> interested in that
> buffer, or for that matter even be able to name it
> (since the new index
> has a new relfilenode value that isn't even visible
> to any other process
> yet). I thought for a little bit that a background
> CHECKPOINT might be
> trying to write out the new buffer, but that theory
> holds no water
> either, because at this point in the _bt_getbuf
> sequence, the buffer is
> not marked dirty (I just verified this by stepping
> through it in 7.4.2).
>
> I can think of lots of reasons why the REINDEX might
> block at the
> previous step of the sequence, namely acquiring a
> fresh buffer ... but
> once it's got the buffer there is surely no reason
> to block.
>
> What I'm inclined to think is that the backtrace
> isn't right at all.
> Would it be possible for you to install a backend
> built with
> --enable-debug and get a more reliable backtrace?
>
> regards, tom lane
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to
majordomo@postgresql.org
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
