From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Jessica Perry Hekman <jphekman(at)dynamicdiagrams(dot)com>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Jan Wieck <janwieck(at)yahoo(dot)com>, Barry Lind <barry(at)xythos(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: timeout implementation issues |
Date: | 2002-04-07 06:08:46 |
Message-ID: | 29604.1018159726@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I consider SET variables metadata that are not affected by transactions.
Why? Again, the fact that historically they've not acted that way isn't
sufficient reason for me.
> 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?
Hm. That's a slightly more interesting example than before ... but it
comes close to arguing that logging should be under transaction control.
Surely you'd not argue that a failed transaction should erase all its
entries from the postmaster log? Why would you expect changes in log
levels to be retroactive?
> 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.
You seem to be suggesting that we should make a variable-by-variable
decision about whether SET variables roll back on ABORT or not. I think
that way madness lies; we could spend forever debating which vars are
which, and then who will remember without consulting the documentation?
I feel we should just do it. Yeah, there might be some corner cases
where it's not the ideal behavior; but you haven't convinced me that
there are more cases where it's bad than where it's good. You sure
haven't convinced me that it's worth making SET's behavior
nigh-unpredictable-without-a-manual, which is what per-variable behavior
would be.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2002-04-07 07:59:16 | Re: timeout implementation issues |
Previous Message | Peter Eisentraut | 2002-04-07 06:01:07 | Re: timeout implementation issues |