Kevin Grittner wrote:
> This may or may not be related to previous threads regarding vacuum problems.
> Following the last thread, we built the development snapshot of Oct 6 with
> --enable-integer-datetimes and --enable-debug. We have had the autovacuum
> running every ten seconds. The only table which will meet the autovacuum
> criteria is a table with 72 rows which is frequently updated. This part was doing
> fine -- keeping the pages to about 20 without any noticable performance hit.
Trivial observation: process 748 is a manually-issued VACUUM (manually,
by cron), it's holding locks other VACUUMs are waiting for, and is
waiting on LockBufferForCleanup. I guess this means it lost a signal,
or somebody else is holding a pin on the buffer. If this is the case,
who is it and why isn't it releasing the pin?
Do we have any tools to display the contents of the buffer cache? We
have pg_buffercache but it'll only display general data, no specifics
(such as who has pins to each buffers).
Maybe GDB could show that info somehow. I'm unable to provide quick
advice on that, though.
--
Alvaro Herrera http://www.advogato.org/person/alvherre
"El número de instalaciones de UNIX se ha elevado a 10,
y se espera que este número aumente" (UPM, 1972)