Re: How to troubleshoot a halted postgres 8.3 ?

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 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 ?

Thanks,

Stefan