Re: database vacuum from cron hanging
От | Kevin Grittner |
---|---|
Тема | Re: database vacuum from cron hanging |
Дата | |
Msg-id | s34bef41.089@gwmta.wicourts.gov обсуждение исходный текст |
Ответ на | database vacuum from cron hanging ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Список | pgsql-hackers |
(gdb) p BufferDescriptors[781] $1 = {tag = {rnode = {spcNode = 1663, dbNode = 16385, relNode = 2666}, blockNum = 1}, flags = 70, usage_count = 5, refcount= 4294967294, wait_backend_pid = 748, buf_hdr_lock = 0 '\0', buf_id = 781, freeNext = -2, io_in_progress_lock = 1615,content_lock = 1616} >>> Tom Lane <tgl@sss.pgh.pa.us> 10/11/05 4:51 PM >>> Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > 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? Yeah, this is clearly the problem --- the other guys waiting are just queued up behind this one. If the system is still in that state, could you reattach to the stuck process and dop BufferDescriptors[781] It might be good to dop BufferDescriptors[782] as well --- I am not sure offhand whether LockBufferForCleanup takes a 0-based or 1-based index, and in any case it's possible gcc would have done something weird with the variable contents. You should see wait_backend_pid = 748 in the one we want. regards, tom lane
В списке pgsql-hackers по дате отправления: