Tom Lane wrote:
> What I propose we do about this is put the same check into TRUNCATE,
> CLUSTER, and REINDEX that is already in ALTER TABLE, namely that we
> reject the command if the current transaction is already holding
> the table open.
> The issue Steven directly complained of is a potential for undetected
> deadlock via LockBufferForCleanup. Ordinarily, buffer-level locks don't
> pose a deadlock risk because we don't hold one while trying to acquire
> another (except in UPDATE, which uses an ordering rule to avoid the
> risk). The problem with LockBufferForCleanup is that it can be blocked
> by a mere pin, which another backend could well hold while trying to
> acquire a lock that will be blocked by VACUUM.
Seems like a hard problem.
I wonder if we can invoke the deadlock checker in LockBufferForCleanup.
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
In response to
pgsql-hackers by date
|Next:||From: Roberts, Jon||Date: 2008-01-22 16:02:44|
|Subject: autonomous transactions|
|Previous:||From: Andrew Dunstan||Date: 2008-01-22 14:41:29|
|Subject: Re: [HACKERS] Errors with run_build.pl - 8.3RC2|
pgsql-patches by date
|Next:||From: Gokulakannan Somasundaram||Date: 2008-01-23 15:58:48|
|Subject: Re: [HACKERS] Including Snapshot Info with Indexes|
|Previous:||From: Greg Sabino Mullane||Date: 2008-01-22 06:18:07|
|Subject: Re: Friendly help for psql|