From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Steven Flatt" <steven(dot)flatt(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #3883: Autovacuum deadlock with truncate? |
Date: | 2008-01-21 18:24:39 |
Message-ID: | 9531.1200939879@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"Steven Flatt" <steven(dot)flatt(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Steven Flatt | 2008-01-21 19:51:16 | Re: BUG #3883: Autovacuum deadlock with truncate? |
Previous Message | Steven Flatt | 2008-01-21 18:14:30 | Re: BUG #3883: Autovacuum deadlock with truncate? |