Re: BUG #3883: Autovacuum deadlock with truncate? - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #3883: Autovacuum deadlock with truncate?
Date
Msg-id 9531.1200939879@sss.pgh.pa.us
Whole thread Raw
In response to BUG #3883: Autovacuum deadlock with truncate?  ("Steven Flatt" <steven.flatt@gmail.com>)
Responses Re: BUG #3883: Autovacuum deadlock with truncate?
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #3881: lo_open leaks memory
Next
From: "Steven Flatt"
Date:
Subject: Re: BUG #3883: Autovacuum deadlock with truncate?