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

Re: Thoughts about bug #3883

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Thoughts about bug #3883
Date: 2008-01-22 15:42:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
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                      
The PostgreSQL Company - Command Prompt, Inc.

In response to

pgsql-hackers by date

Next:From: Roberts, JonDate: 2008-01-22 16:02:44
Subject: autonomous transactions
Previous:From: Andrew DunstanDate: 2008-01-22 14:41:29
Subject: Re: [HACKERS] Errors with - 8.3RC2

pgsql-patches by date

Next:From: Gokulakannan SomasundaramDate: 2008-01-23 15:58:48
Subject: Re: [HACKERS] Including Snapshot Info with Indexes
Previous:From: Greg Sabino MullaneDate: 2008-01-22 06:18:07
Subject: Re: Friendly help for psql

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