> > > I doubt if it's a bug of SELECT. Well what
> > > 'concurrent UPDATE then SELECT FOR UPDATE +
> > > SELECT' return ?
> >
> > I'm going to add additional check to heapgettup and
> > heap_fetch:
>
> SELECT seems to be able to return a different result
> from that of preceding SELECT FOR UPDATE
Forest Wilkinson <[EMAIL PROTECTED]> writes:
> Good point. How long is the next cycle likely to take?
Good question. I'd like to say 4 to 6 months, but that was how long 7.1
was supposed to take, and we're pushing a year now.
What might make the most sense is to develop and test a fix in the e
On Thursday 29 March 2001 22:15, Tom Lane wrote:
> > Just looked in heapam.c - I can fix it in two hours.
> > The question is - should we do this now?
>
> This scares the hell out of me.
>
> I do NOT think we should be making quick-hack changes in fundamental
> system semantics at this point of th
> > >> I assume this is not possible in 7.1?
> > >
> > >Just looked in heapam.c - I can fix it in two hours.
> > >The question is - should we do this now?
> > >Comments?
> >
> > It's a bug; how confident are you of the fix?
95% -:)
> I doubt if it's a bug of SELECT. Well what
> 'concurrent UPDAT
> >Reported problem is caused by bug (only one tuple version must be
> >returned by SELECT) and this is way to fix it.
> >
>
> I assume this is not possible in 7.1?
Just looked in heapam.c - I can fix it in two hours.
The question is - should we do this now?
Comments?
Vadim
---
"Mikheev, Vadim" wrote:
>
> > > >> I assume this is not possible in 7.1?
> > > >
> > > >Just looked in heapam.c - I can fix it in two hours.
> > > >The question is - should we do this now?
> > > >Comments?
> > >
> > > It's a bug; how confident are you of the fix?
>
> 95% -:)
>
> > I doubt if it'
At 13:16 30/03/01 +0900, Hiroshi Inoue wrote:
>Philip Warner wrote:
>>
>> At 19:14 29/03/01 -0800, Mikheev, Vadim wrote:
>> >> >Reported problem is caused by bug (only one tuple version must be
>> >> >returned by SELECT) and this is way to fix it.
>> >> >
>> >>
>> >> I assume this is not possible
> Just looked in heapam.c - I can fix it in two hours.
> The question is - should we do this now?
This scares the hell out of me.
I do NOT think we should be making quick-hack changes in fundamental
system semantics at this point of the release cycle.
The problem went unnoticed for two full rel
At 19:14 29/03/01 -0800, Mikheev, Vadim wrote:
>> >Reported problem is caused by bug (only one tuple version must be
>> >returned by SELECT) and this is way to fix it.
>> >
>>
>> I assume this is not possible in 7.1?
>
>Just looked in heapam.c - I can fix it in two hours.
>The question is - shoul
Philip Warner wrote:
>
> At 19:14 29/03/01 -0800, Mikheev, Vadim wrote:
> >> >Reported problem is caused by bug (only one tuple version must be
> >> >returned by SELECT) and this is way to fix it.
> >> >
> >>
> >> I assume this is not possible in 7.1?
> >
> >Just looked in heapam.c - I can fix it
At 09:58 28/03/01 -0800, Mikheev, Vadim wrote:
>
>Reported problem is caused by bug (only one tuple version must be
>returned by SELECT) and this is way to fix it.
>
I assume this is not possible in 7.1?
Philip Warner
> > I don't think that we dare try to make any basic changes in
> > MVCC for 7.1 at this late hour, so Forest is going to have
> > to live with that answer for awhile. But I would like to see
> > a cleaner answer in future releases.
>
> Is it the MVCC's restriction that each query inside a functi
Tom Lane wrote:
>
> Philip Warner <[EMAIL PROTECTED]> writes:
> >> The workaround for Forest is to make the final SELECT be a SELECT FOR
> >> UPDATE, so that it's playing by the same rules as the earlier commands.
>
> > Eek. Does this seem good to you?
>
> I did call it a workaround ;-)
>
> I d
On Tuesday 27 March 2001 15:14, Tom Lane wrote:
> Forest Wilkinson <[EMAIL PROTECTED]> writes:
> > session1<< create function nextid( varchar(32)) returns int8 as '
> > session1<< select * from idseq where name = $1::text for update;
> > session1<< update idseq set id = id + 1 where name = $1:
Forest Wilkinson <[EMAIL PROTECTED]> writes:
> If I remember correctly, UPDATE establishes a lock on the affected rows,
> which will block another UPDATE on the same rows for the duration of the
> transaction. If that's true, shouldn't I be able to achieve my desired
> behavior by removing the
Philip Warner <[EMAIL PROTECTED]> writes:
>> The workaround for Forest is to make the final SELECT be a SELECT FOR
>> UPDATE, so that it's playing by the same rules as the earlier commands.
> Eek. Does this seem good to you?
I did call it a workaround ;-)
I don't think that we dare try to make
At 18:14 27/03/01 -0500, Tom Lane wrote:
>Forest Wilkinson <[EMAIL PROTECTED]> writes:
>> session1<< create function nextid( varchar(32)) returns int8 as '
>> session1<< select * from idseq where name = $1::text for update;
>> session1<< update idseq set id = id + 1 where name = $1::text;
>> s
Forest Wilkinson <[EMAIL PROTECTED]> writes:
> session1<< create function nextid( varchar(32)) returns int8 as '
> session1<< select * from idseq where name = $1::text for update;
> session1<< update idseq set id = id + 1 where name = $1::text;
> session1<< select id from idseq where name =
18 matches
Mail list logo
