| From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Thomas Lockhart <lockhart(at)fourpalms(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Michael Loftis <mloftis(at)wgops(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: timeout implementation issues |
| Date: | 2002-04-19 00:19:16 |
| Message-ID: | 3CBF6284.B36ABC5A@tpf.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
>
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > I don't think this is *all* *should be* or *all
> > or nothing* kind of thing. If a SET variable has
> > its reason, it would behave in its own right.
>
> Well, we could provide some kind of escape hatch to let the behavior
> vary from one variable to the next. But can you give any specific
> examples? Which SET variables should not roll back on error?
It seems veeery dangerous to conclude that SET *should*
roll back even if there's no *should not* roll back case.
There could be no *should not* roll back case because
a user could set the variable as he likes in the next
transaction.
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oliver Elphick | 2002-04-19 00:25:22 | Re: Schema (namespace) privilege details |
| Previous Message | Michael Loftis | 2002-04-19 00:18:31 | Re: Index Scans become Seq Scans after VACUUM ANALYSE |