Re: timeout implementation issues - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: timeout implementation issues
Date
Msg-id 200204031836.g33IaXQ09754@candle.pha.pa.us
Whole thread Raw
In response to Re: timeout implementation issues  (Jessica Perry Hekman <jphekman@dynamicdiagrams.com>)
Responses Re: timeout implementation issues  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: timeout implementation issues  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
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:
parseerror at or near "asdf"test=> SET server_min_messages to 'debug1';WARNING:  current transaction is aborted,
queriesignored until end oftransaction block*ABORT STATE*test=> COMMIT;COMMITtest=> SHOW server_min_messages;INFO:
server_min_messagesis 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,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Suggestions please: names for function cachabilityattributes
Next
From: mlw
Date:
Subject: Re: Suggestions please: names for function