Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.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.
I think it is broken. What logic is there that SET before transaction
abort is performed, but after abort it is ignored? What if someone
wants a specific optimizer parameter for a statement in a transaction,
like geqo_* or enable_seqscan off, and they perform the SET before the
statement OK but if the statement fails, the SET after it is ignored.
That doesn't seem like very normal behavior to me.
We are seeing this in the timeout case, but in fact the other SET
commands when run in a transaction have the same problem.
> > 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.
Yes, I now think that saving the SET commands that are ignored in a
transaction and running them _after_ the transaction completes may be
the best thing. They can be stored as C strings in a stable memory
context and just run on transaction completion.
If we don't somehow get this to work, how do we do timeouts, which we
all know we should have?
-- 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
