Alvaro Herrera escribió:
>
> This one really works and includes a basic test case. You were right
> that the extra Register was bogus :-( I had to expose CopySnapshot,
> which I still don't like but ... (I could have added an extra
> Unregister somewhere during portal close, but it would have m
This one really works and includes a basic test case. You were right
that the extra Register was bogus :-( I had to expose CopySnapshot,
which I still don't like but ... (I could have added an extra
Unregister somewhere during portal close, but it would have meant making
everything messier).
-
Tom Lane escribió:
> Alvaro Herrera writes:
> > Tom Lane escribi�:
> >> I don't think that testing rowMarks is the right thing at all here.
> >> That tells you whether it's a SELECT FOR UPDATE, but actually we
> >> want any cursor (and only cursors) to have a private snapshot.
>
> > The attached
Alvaro Herrera writes:
> Tom Lane escribió:
>> I don't think that testing rowMarks is the right thing at all here.
>> That tells you whether it's a SELECT FOR UPDATE, but actually we
>> want any cursor (and only cursors) to have a private snapshot.
> The attached patch implements this. I intend
Tom Lane escribió:
> Alvaro Herrera writes:
> > Tom Lane escribió:
> >> Well, the first problem is that 8.4 is failing to duplicate the
> >> historical behavior.
>
> > Oh! That's easy.
>
> I don't think that testing rowMarks is the right thing at all here.
> That tells you whether it's a SELECT
Tom Lane escribió:
> Alvaro Herrera writes:
> > Tom Lane escribió:
> >> Well, the first problem is that 8.4 is failing to duplicate the
> >> historical behavior.
>
> > Oh! That's easy.
>
> I don't think that testing rowMarks is the right thing at all here.
> That tells you whether it's a SELECT
Alvaro Herrera writes:
> Tom Lane escribió:
>> Well, the first problem is that 8.4 is failing to duplicate the
>> historical behavior.
> Oh! That's easy.
I don't think that testing rowMarks is the right thing at all here.
That tells you whether it's a SELECT FOR UPDATE, but actually we
want an
Tom Lane escribió:
> Alvaro Herrera writes:
> > Tom Lane escribi�:
> >> I think we need to ensure that when a cursor is created, it obtains a
> >> private copy of the current snapshot ... but I'm not sure where that
> >> ought to happen. Thoughts?
>
> > Maybe you are right, but I don't think tha
Alvaro Herrera writes:
> Tom Lane escribió:
>> I think we need to ensure that when a cursor is created, it obtains a
>> private copy of the current snapshot ... but I'm not sure where that
>> ought to happen. Thoughts?
> Maybe you are right, but I don't think that's the only bug here.
Well, the
Alvaro Herrera escribió:
> I played a bit with doing this only when the OPT_CURSOR_INSENSITIVE bit
> is set, but I'm not ever seeing it set -- with or with FOR UPDATE ...
Oh, I see, that's a grammar only bit. I need to check rowMarks == NIL
instead. It doesn't help anyway but at least I figured
Tom Lane escribió:
> Alvaro Herrera writes:
> > Interesting. If I create an non-unique index on the table before
> > declaring the cursor, FETCH throws an error:
>
> > alvherre=# fetch all from c1;
> > ERROR: attempted to lock invisible tuple
>
> I get that in 8.4 and HEAD even without any ind
Alvaro Herrera writes:
> Interesting. If I create an non-unique index on the table before
> declaring the cursor, FETCH throws an error:
> alvherre=# fetch all from c1;
> ERROR: attempted to lock invisible tuple
I get that in 8.4 and HEAD even without any index, just trying the given
case. It
Daniel F escribió:
> SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL SERIALIZABLE;
> begin;
> show transaction isolation level;
> create table foo (a bigint);
> insert into foo select generate_series(0, 9);
> declare c1 no scroll cursor for select * from foo for update;
> update foo set
Hi -
I'm seeing a behavior with updatable cursors that matches neither the
behavior
of a sensitive cursor nor an insensitive one. In summary, I'm running with
serializable as the isolation level and rows updated within the same
transaction seem to disappear under the cursor.
>From the postgres d
14 matches
Mail list logo
