Re: problem with new autocommit config parameter and jdbc
От | scott.marlowe |
---|---|
Тема | Re: problem with new autocommit config parameter and jdbc |
Дата | |
Msg-id | Pine.LNX.4.33.0209101145230.4854-100000@css120.ihs.com обсуждение исходный текст |
Ответ на | Re: problem with new autocommit config parameter and jdbc (Stephan Szabo <sszabo@megazone23.bigpanda.com>) |
Ответы |
Re: problem with new autocommit config parameter and jdbc
Re: problem with new autocommit config parameter and jdbc |
Список | pgsql-hackers |
On Tue, 10 Sep 2002, Stephan Szabo wrote: > > > > > It starts a transaction, failes the first command and goes into the > > > > > error has occurred in this transaction state. Seems like reasonable > > > > > behavior. > > > > > > > > Select command don't start transaction - it is not good > > > > > > I think you need more justification than "it is not good." If I do a > > > sequence of select statements in autocommit=false, I'd expect the same > > > consistancy as if I'd done > > > begin; > > > select ...; > > > select ...; > > > > > Ok.You start transaction explicit and this is ok. > > But simple SELECT don't start transaction. > > Actually someone post a bit from Date's book that implies it does. > And, that's still not an justification, it's just a restating of same > position. I don't see any reason why the two should be different from > a data consistency standpoint, there might be one, but you haven't > given any reasons. What if it's a select for update? IF that failed because of a timout on a lock, shouldn't the transaction fail? Or a select into? Either of those should make a transaction fail, and they're just selects.
В списке pgsql-hackers по дате отправления: