| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Jessica Perry Hekman <jphekman(at)dynamicdiagrams(dot)com>, Barry Lind <barry(at)xythos(dot)com>, Jan Wieck <janwieck(at)yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: timeout implementation issues |
| Date: | 2002-04-04 15:25:10 |
| Message-ID: | 23527.1017933910@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I think we have only a few options:
You forgot
o Do nothing.
IMHO the current behavior is not broken, and does not need fixed.
All of the options you suggest are surely more broken than the current
behavior.
> o Issue a RESET on transaction completion (commit or abort) for any
> SET variable set in the transaction. (This will cause problems
> for API's like ecpg which are always in a transaction.)
RESET would certainly not be a desirable behavior. If we want SET vars
to roll back on abort, then they should roll back --- ie, resume their
transaction-start-time values. But I doubt it's worth the trouble.
That behavior would do nothing to help JDBC implement timeouts, since
they'd still need to change the value again explicitly after successful
transaction completion.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2002-04-04 15:31:47 | Re: Bidirectional hard joins (fwd) |
| Previous Message | Tom Lane | 2002-04-04 15:13:18 | Re: What's the CURRENT schema ? |