Re: timeout implementation issues

Tom Lane writes:

> I didn't say "transaction specific". I said that if you do a SET inside
> a transaction block, and then the transaction is aborted, the effects of
> the SET ought to roll back along with everything else you did inside
> that transaction block. I'm not seeing what the argument is against
> this.

I consider SET variables metadata that are not affected by transactions.
I should be able to change my mind about my session preferences in the
middle of a transaction, no matter what happens to the data in it. Say
somewhere in the middle of a long transaction I think, "I should really be
logging this stuff". I turn a knob to do so, and the next command fails.
Is the failure logged? In which order does the rollback happen? What if
I want to continue logging?

If anything were to change I would like to continue accepting SET commands
after an error. Of course, I would like to continue accepting any command
after an error, but that's a different debate.

I guess it's a matter of definition: Do you consider SET variables
database state or session metadata? I think some are this and some are
that. I'm not sure how to draw the line, but throwing everything from one
category into the other isn't my favorite solution.

--
Peter Eisentraut peter_e(at)gmx(dot)net