Re: timeout implementation issues
От
Bruce Momjian
Тема
Re: timeout implementation issues
Дата
Msg-id
200204031836.g33IaXQ09754@candle.pha.pa.us
Ответ на
Re: timeout implementation issues (Jessica Perry Hekman)
Список
Дерево обсуждения
timeout implementation issues Jessica Perry Hekman <jphekman@dynamicdiagrams.com>
Re: timeout implementation issues Tom Lane <tgl@sss.pgh.pa.us>
Re: timeout implementation issues Bruce Momjian <pgman@candle.pha.pa.us>
Re: timeout implementation issues Jessica Perry Hekman <jphekman@dynamicdiagrams.com>
Re: timeout implementation issues Tom Lane <tgl@sss.pgh.pa.us>
Re: timeout implementation issues Jessica Perry Hekman <jphekman@dynamicdiagrams.com>
Re: timeout implementation issues Tom Lane <tgl@sss.pgh.pa.us>
Re: timeout implementation issues Jessica Perry Hekman <jphekman@dynamicdiagrams.com>
Re: timeout implementation issues Jessica Perry Hekman <jphekman@dynamicdiagrams.com>
Re: timeout implementation issues Bruce Momjian <pgman@candle.pha.pa.us>
Re: timeout implementation issues Tom Lane <tgl@sss.pgh.pa.us>
Re: timeout implementation issues Jan Wieck <janwieck@yahoo.com>
Re: timeout implementation issues Jessica Perry Hekman <jphekman@dynamicdiagrams.com>
Re: timeout implementation issues Tom Lane <tgl@sss.pgh.pa.us>
Re: timeout implementation issues Jessica Perry Hekman <jphekman@dynamicdiagrams.com>
Re: timeout implementation issues Bruce Momjian <pgman@candle.pha.pa.us>
Re: timeout implementation issues Jessica Perry Hekman <jphekman@dynamicdiagrams.com>
Re: timeout implementation issues Bruce Momjian <pgman@candle.pha.pa.us>
Re: timeout implementation issues Jessica Perry Hekman <jphekman@dynamicdiagrams.com>
Jessica Perry Hekman wrote: > On Tue, 2 Apr 2002, Barry Lind wrote: > > > Since both the JDBC and ODBC specs have essentially the same symantics > > for this, I would hope this is done in the backend instead of both > > interfaces. > > The current plan seems to be to make changes in the backend and the JDBC > interface, the bulk of the implementation being in the backend. Yes, ODBC and JDBC need this, and I am sure psql folks will use it too, not counting libpq and all the others. We just need a way to specify statement-level SET options inside a transaction where the statement may fail and ignore the SET command that resets the timeout. We don't have any mechanism to reset the timeout parameter at the end of a transaction automatically, which would solve our problem with failed transactions. Does anyone know the ramifications of allowing SET to work in an aborted transaction? It is my understanding that SET doesn't really have transaction semantics anyway, e.g. a SET that is done in a transaction that is later aborted is still valid: test=> BEGIN;BEGINtest=> SET server_min_messages to 'debug5';SET VARIABLEtest=> ABORT;ROLLBACKtest=> SHOW server_min_messages;INFO: server_min_messages is debug5SHOW VARIABLE Having shown this, it could be argued that SET should work in an already-aborted transaction. Why should having the SET before or after the transaction is canceled have any effect. This illustrates it a little clearer:test=> BEGIN;BEGINtest=> SET server_min_messages to 'debug3';SET VARIABLEtest=> asdf; ERROR: parser: parse error at or near "asdf"test=> SET server_min_messages to 'debug1';WARNING: current transaction is aborted, queries ignored until end oftransaction block*ABORT STATE*test=> COMMIT;COMMITtest=> SHOW server_min_messages;INFO: server_min_messages is debug3SHOW VARIABLEtest=> Why should the 'debug3' be honored if the transaction aborted. And if it is OK that is was honored, is it OK that the 'debug1' was not honored? Allowing SET to be valid after a transaction aborts would solve our SET timeout problem. There is also a feeling that people may want to set maximum counts for transactions too because the transaction could be holding locks you want released. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
В списке pgsql-hackers по дате отправления
От: Tom Lane
Дата: