possible row locking bug in 7.0.3 & 7.1

From: Forest Wilkinson <fspam(at)home(dot)com>
To: pgsql-sql(at)postgresql(dot)org
Subject: possible row locking bug in 7.0.3 & 7.1
Date: 2001-03-27 21:10:16
Message-ID: 01032713101600.07241@bartok
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-sql

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 seeing:
(psql input represented by '<<'; output represented by '>>'.)

session1<< create table idseq
session1<< (
session1<< name varchar(32) not null,
session1<< id int8 not null default 0
session1<< );
session1>> CREATE

session1<< insert into idseq values ('myid');
session1>> INSERT 18734 1

Each row in the table is supposed to represent a named numeric sequence,
much like the sequences built into postgres. (Mine use an int8 though,
so their values can be much higher.)

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';
session1>> CREATE

The idea here is that the select...for update within the nextid() function
will establish a row level lock, preventing two concurrent function calls
from overlapping.

Next, I test with two sessions as follows:

session1<< begin;
session1>> BEGIN

session2<< begin;
session2>> BEGIN

session1<< select nextid('myid');
session1>> nextid
session1>> --------
session1>> 1
session1>> (1 row)

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!

session2<< commit;
session2>> COMMIT

session2<< select * from idseq;
session2>> name | id
session2>> ------+----
session2>> myid | 2
session2>> (1 row)

session1<< select * from idseq;
session1>> name | id
session1>> ------+----
session1>> myid | 2
session1>> (1 row)

As you can see, my nextid() function is not synchronized the way I hoped.
I don't know why, though. Can someone help? I'm going to try out some of my
SPI functions with 7.1 beta 6, to see if they exhibit a locking problem as
well.

Thanks,

Forest Wilkinson

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-03-27 21:33:17 Re: IANA registration
Previous Message thomas graichen 2001-03-27 21:00:40 Re: Re: Call for platforms

Browse pgsql-sql by date

  From Date Subject
Next Message Jeff Eckermann 2001-03-27 21:43:22 RE: pl/pgsql and returning rows
Previous Message Diehl, Jeffrey 2001-03-27 20:28:00 RE: Replace into...?