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::text;
> > session1<< select id from idseq where name = $1::text;
> > session1<< ' language 'sql';
> > [ doesn't work as expected in parallel transactions ]
[snip]
> 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.
> But I wonder whether we ought to rethink the MVCC rules so that that's
> not necessary. I have no idea how we might change the rules though.
> If nothing else, we should document this issue better: SELECT and SELECT
> FOR UPDATE have different visibility rules, so you probably don't want
> to intermix them.
My, that's ugly. (But thanks for the workaround.)
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 initial as follows:
create function nextid( varchar(32)) returns int8 as '
update idseq set id = id + 1 where name = $1::text;
select id from idseq where name = $1::text;
' language 'sql';
Or, would I still have to add FOR UPDATE to that final SELECT?
Forest
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
