Re: timeout implementation issues

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Jessica Perry Hekman <jphekman(at)dynamicdiagrams(dot)com>
Cc: Barry Lind <barry(at)xythos(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jan Wieck <janwieck(at)yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: timeout implementation issues
Date: 2002-04-03 18:36:33
Message-ID: 200204031836.g33IaXQ09754@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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;
BEGIN
test=> SET server_min_messages to 'debug5';
SET VARIABLE
test=> ABORT;
ROLLBACK
test=> SHOW server_min_messages;
INFO: server_min_messages is debug5
SHOW 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;
BEGIN
test=> SET server_min_messages to 'debug3';
SET VARIABLE
test=> 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 of
transaction block
*ABORT STATE*
test=> COMMIT;
COMMIT
test=> SHOW server_min_messages;
INFO: server_min_messages is debug3
SHOW VARIABLE
test=>

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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-04-03 18:41:14 Re: Re : Solaris Performance - Profiling (Solved)
Previous Message Tom Lane 2002-04-03 18:29:40 Re: Suggestions please: names for function cachabilityattributes