Re: BUG #3883: Autovacuum deadlock with truncate?
От | Tom Lane |
---|---|
Тема | Re: BUG #3883: Autovacuum deadlock with truncate? |
Дата | |
Msg-id | 9531.1200939879@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #3883: Autovacuum deadlock with truncate? ("Steven Flatt" <steven.flatt@gmail.com>) |
Ответы |
Re: BUG #3883: Autovacuum deadlock with truncate?
|
Список | pgsql-bugs |
"Steven Flatt" <steven.flatt@gmail.com> writes: > (gdb) f 3 > (gdb) p *bufHdr > $1 = {tag = {rnode = {spcNode = 1663, dbNode = 16384, relNode = 16648}, > blockNum = 3}, flags = 70, usage_count = 0, refcount = 2, > wait_backend_pid = 23965, buf_hdr_lock = 0 '\0', buf_id = 501, > freeNext = -2, io_in_progress_lock = 1121, content_lock = 1122} > (gdb) p PrivateRefCount[501] > $2 = 1 > pid 7908 (function to clean tables) > (gdb) p PrivateRefCount[501] > $1 = 2 Well, there's our problem: for some reason PID 7908 has this buffer pinned, which is blocking the vacuum. That seems pretty darn odd for a process that is about to (try to) truncate the table. The only way I can imagine is that the function has an open cursor scanning the table ... which is a case that we probably ought to error out on, though I think TRUNCATE is not checking for it now. Or you've managed to tickle some previously-unknown bug that leaks buffer pins. Could we see that whole function? Also, what has been done previously in the transaction that's calling it? regards, tom lane
В списке pgsql-bugs по дате отправления: