Re: ALTER TABLE deadlock with concurrent INSERT

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER TABLE deadlock with concurrent INSERT
Date: 2011-03-02 20:41:43
Message-ID: 13960.1299098503@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joe Conway <mail(at)joeconway(dot)com> writes:
> I'm working with a client on an application upgrade script which
> executes a function to conditionally do an:

> ALTER TABLE foo ALTER COLUMN bar SET DATA TYPE baz

> If this is run while the application is concurrently doing inserts into
> foo, we are occasionally seeing deadlocks. Aside from the fact that they
> are better off not altering the table amid concurrent inserts, I'm
> trying to understand why this is even able to happen. I expect one to
> block the other, not a deadlock.

Looks like the process trying to do the ALTER has already got some
lower-level lock on the table. It evidently hasn't got
AccessExclusiveLock, but nonetheless has something strong enough to
block an INSERT, such as ShareLock.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2011-03-02 20:44:44 Re: Sync Rep v17
Previous Message Simon Riggs 2011-03-02 20:39:08 Re: Sync Rep v17