> > > 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 =
I'm having a problem with functions written in SQL. Specifically, they
don't seem to be adhering to Postgres locking rules. For the record, I'm
using postgres 7.0.3, installed from RPMs, on Red Hat 6.2. I got the same
results with postgres 7.1 beta 6, installed from sources.
Here's what I'm s
19 matches
Mail list logo
