Bryan Brunton wrote:
> Turning off that option fixed the problem. I'm concerned that the
> back-end
> should be effected by this. Shouldn't it be able to recover from
> confusing
> statements that a ODBC driver sends it, rather than locking up like
> this?
>
The reason it locked up with the declare/fetch option ON is because postgres
cursors require a transaction to be started. The table being viewed inside
the transaction is then locked from any other process even viewing it.
Without the declare/fetch option, no transactions are used, so it works.
The simple explanation is that the backend locking strategy needs to be
improved. This is a well-known limitation of postgres that is being worked
on (I believe by Vadim). He mentioned something recently on the hackers
list about working on readers not locking other readers, which is exactly
what is happening here. Sounded interesting.
Byron
