| 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-18 23:53:02 |
| Message-ID: | 3CBF5C5E.9191AEF9@tpf.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
>
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I have updated the TODO to:
> > o Abort all or commit all SET changes made in an aborted transaction
> > I don't think our current behavior is defended by anyone.
>
> Hiroshi seems to like it ...
Probably I don't love it. Honestly I don't understand
what the new TODO means exactly.
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.
> However, "commit SETs even after an error" is most certainly NOT
> acceptable.
What I've meant is that SET commands are out of transactional
control and so the word *commit SETs even after* has no meaning
to me. Basically it's a user's responsisbilty to manage the
errors. He only knows what's to do with the errors.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-04-18 23:56:13 | Re: timeout implementation issues |
| Previous Message | Tom Lane | 2002-04-18 23:48:35 | Re: Schema (namespace) privilege details |