| From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
|---|---|
| To: | "'Zeugswetter Andreas SB'" <ZeugswetterA(at)wien(dot)spardat(dot)at>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "'Hiroshi Inoue'" <Inoue(at)tpf(dot)co(dot)jp>, Philip Warner <pjw(at)rhyme(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | RE: AW: Re: [SQL] possible row locking bug in 7.0.3 & 7 .1 |
| Date: | 2001-03-30 20:08:44 |
| Message-ID: | 8F4C99C66D04D4118F580090272A7A234D3362@sectorbase1.sectorbase.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > This will take thought, research and discussion. A quick fix is the
> > last thing that should be on our minds.
>
> From my latest tests( see following post), I tend to agree,
> that this is extremely sensitive :-(
> I do however think that Vadim's patch description was the
> correct thing to do.
To avoid double tuple versions return - maybe.
To get same results from SELECT and SELECT FOR UPDATE in functions -
no time for 7.1.
> The problem case seems to be when the function is not
> executed inside a txn.
Any query is executed inside TX. All queries of a function
are executed in the same TX.
Vadim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dominic J. Eidson | 2001-03-30 20:20:17 | Re: Re: third call for platforms... |
| Previous Message | Mikheev, Vadim | 2001-03-30 20:02:34 | RE: AW: Re: [SQL] possible row locking bug in 7.0.3 & 7 .1 |