Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

Next:From: Steven FlattDate: 2008-01-21 19:51:16
Subject: Re: BUG #3883: Autovacuum deadlock with truncate?
Previous:From: Steven FlattDate: 2008-01-21 18:14:30
Subject: Re: BUG #3883: Autovacuum deadlock with truncate?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group