Re: SQL functions not locking properly?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-sql(at)hub(dot)org
Subject: Re: SQL functions not locking properly?
Date: 2000-09-25 20:26:16
Message-ID: 6910.969913576@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Forest Wilkinson <fspam(at)home(dot)com> writes:
> session2<< select nextid('myid');

> (session2 blocks until session1 completes its transaction)

> session1<< commit;
session1> COMMIT

> (session2 resumes)

session2> nextid
session2> --------
session2> 0
session2> (1 row)

> What gives??? I expected the second call to nextid() to return 2!

Hmm. If you do the same commands without wrapping them in an SQL
function, they operate as expected. I'll bet there's some nasty
interaction between the FOR UPDATE support and the way that SQL
functions twiddle the current-command counter. Sigh, another bug.

You might try it in plpgsql to see if that language has the same
bug (and please report back the results!). If so, the only workaround
right now is not to use a function, or possibly to code it in C using
the SPI interface.

I'm up to my armpits in subselect-in-FROM right now, but will put this
on my to-do list. Will look at it in a week or two if no one else has
fixed it before then...

regards, tom lane

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Tom Lane 2000-09-25 20:29:03 Re: Subqueries in from clause?
Previous Message Forest Wilkinson 2000-09-25 18:46:50 SQL functions not locking properly?