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: | 20080122154239.GC10897@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-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.
+1.
> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Roberts, Jon | 2008-01-22 16:02:44 | autonomous transactions |
Previous Message | Andrew Dunstan | 2008-01-22 14:41:29 | Re: [HACKERS] Errors with run_build.pl - 8.3RC2 |
From | Date | Subject | |
---|---|---|---|
Next Message | Gokulakannan Somasundaram | 2008-01-23 15:58:48 | Re: [HACKERS] Including Snapshot Info with Indexes |
Previous Message | Greg Sabino Mullane | 2008-01-22 06:18:07 | Re: Friendly help for psql |