On 03/03/2011 11:36 PM, Noah Misch wrote:
> Does relation 16902 (attribute_summary) have a foreign key constraint over the
> sequence_number column, in either direction, with relation 16896? That would
> explain it:
>
> session 1: ALTER TABLE attribute_summary ... transformAlterTableStmt>
> sess
On Wed, Mar 02, 2011 at 12:25:16PM -0800, Joe Conway wrote:
> 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 inse
On Mar 3, 2011, at 6:26 PM, Joe Conway wrote:
> On 03/03/2011 03:49 PM, Jim Nasby wrote:
>> On Mar 2, 2011, at 2:54 PM, Joe Conway wrote:
>>> On 03/02/2011 12:41 PM, Tom Lane wrote:
Looks like the process trying to do the ALTER has already got some
lower-level lock on the table. It evide
On 03/03/2011 03:49 PM, Jim Nasby wrote:
> On Mar 2, 2011, at 2:54 PM, Joe Conway wrote:
>> On 03/02/2011 12:41 PM, Tom Lane wrote:
>>> 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 nonethe
On Mar 2, 2011, at 2:54 PM, Joe Conway wrote:
> On 03/02/2011 12:41 PM, Tom Lane wrote:
>> 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
On 03/02/2011 12:41 PM, Tom Lane wrote:
> 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.
Hmmm, is it possible th
Joe Conway 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 d
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
