| From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: PL/pgSQL bug? |
| Date: | 2001-08-13 16:56:02 |
| Message-ID: | 3B7806A2.92515937@tpf.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> > It's possible for a function to use a unique snapshot
> > if there are only SELECT statements in the function
> > but it's impossible if there are UPDATE/DELETE or
> > SELECT .. FOR UPDATE statements etc.
>
> You are confusing
No.
> snapshots (which determine visibility of the results
> of OTHER transactions)
Yes.
> with command-counter incrementing (which
> determines visibility of the results of OUR OWN transaction).
Yes.
> I agree
> that plpgsql's handling of command-counter changes is broken,
Probably yes but
> but it
> does not follow that sprinkling the code with SetQuerySnapshot is wise.
>
Should both command counter and snapshots be changed
properly ? Please explain me why/how we could do with
no snapshot change in read committed mode.
regards,
Hiroshi Inoue
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hiroshi Inoue | 2001-08-13 16:56:31 | Re: PL/pgSQL bug? |
| Previous Message | Bruce Momjian | 2001-08-13 16:27:50 | Re: Rename config.h to pg_config.h? |