Hi Scott,
> Remember, alter table statements require a full table lock. So if that
> transaction (including your update statements) doesn't end somehow (commit,
> rollback) then all other connections looking at that table will wait.
> Look at the pg_stat_activity and pg_locks views.
Thanks, you were right, I added an additional commit which solved the problem. The hint was that the pg_lock view
containeda 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
querywould see the data as it was before the start of the transaction, which in my case would have been fine since the
additionalcolumns created by the alter statement were not used in the select which blocked.
Is this some kind of "simple" implementation of a committed read ?
Thanks,
Stefan
