Re: BUG #3883: Autovacuum deadlock with truncate?

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

In response to

Responses

Browse pgsql-bugs by date

  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?