On Wed, Oct 21, 2009 at 3:05 AM, stefan <ste...@intermediate.de> wrote:
> > > > Thanks, you were right, I added an additional commit which solved the > problem. The hint was that the pg_lock view contained a lock entry which > said granted "No". > > This raises though the question of isolation level, afaik postgres default > is committed read. The doc says that another query would see the data as it > was before the start of the transaction, which in my case would have been > fine since the additional columns created by the alter statement were not > used in the select which blocked. > Is this some kind of "simple" implementation of a committed read ? > Right, but that's only for statements that don't take a full table lock. Since your 'ALTER' statement was locking the whole table, those rules don't apply -- i.e. Everyone even looking (selecting) the table would wait, even if they didn't care about the new columns. ALTER is a full lock, no matter what. --Scott
