Re: How to troubleshoot a halted postgres 8.3 ?

On Wed, Oct 21, 2009 at 3:05 AM, stefan <stefan(at)intermediate(dot)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