Re: add primary key doesn't block?

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: add primary key doesn't block?
Date: 2010-01-22 03:30:25
Message-ID: 4B591BD1.2080103@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Jaime Casanova wrote:
> Hi,
>
> I'm testing the migration procedure for a client, we want to migrate
> from 8.3.6 to 8.4
>
> When we perform a test migration of the data we found some errors on
> the logs, one of them is this one:
>
> """
> mic=# ALTER TABLE tcom_invitacion ADD primary key (id_invitacion);
> NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index
> "tcom_invitacion_pkey" for table "tcom_invitacion"
> ERROR: concurrent insert in progress
> """

How was your migration done? pg_dump of data _and_ schema, then `psql
-f' to restore it to the 8.4 database? Some other way?

Was the dump file edited?

Were any other users connected to the DB being restored to at the time?

If you try the restore again to a fresh database (create a new one just
for testing) does the issue happen again?

If so, can you potentially grant one of the Pg team access to a spare
server with the data and problem DB on it, or supply them with a dump
for testing?

Can you supply the full log, or at least some more context?

> doesn't the index creation of the index block the table so, that
> message should not appear?

CREATE INDEX (without CONCURRENTLY) takes a lock on the table that
blocks INSERT/UPDATE/DELETE (but not SELECT), yes.

--
Craig Ringer

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Jaime Casanova 2010-01-22 04:35:58 Re: add primary key doesn't block?
Previous Message Allen Johnson 2010-01-21 21:27:57 Re: BUG #5294: Sorts on more than just the order-by clause