On Wed, Oct 21, 2009 at 3:05 AM, stefan <stefan@xxxxxxxxxxxxxxx> wrote:
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
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
