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
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера