Skip site navigation (1) Skip section navigation (2)

AW: Re: [SQL] possible row locking bug in 7.0.3 & 7.1

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'tgl(at)sss(dot)pgh(dot)pa(dot)us'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'Mikheev, Vadim'" <vmikheev(at)SECTORBASE(dot)COM>
Cc: "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: AW: Re: [SQL] possible row locking bug in 7.0.3 & 7.1
Date: 2001-03-30 16:04:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> To the rest on the list:
> Try the above example by adding a lock between the two lines:
> create function nextid( varchar(32)) returns int8 as '
>     update idseq set id = id + 1 where name = $1::text;
>     select * from lock1;
>     select id from idseq where name = $1::text for update;
>     ' language 'sql';
> 						session1:
> 							begin work;
> 							lock table lock1 in access exclusive mode;
> session 2:
> 	not in txn: select nextid('one'); // this blocks
> 							select nextid('one');
> 							commit work;
> And stare at the results you get with and without for update :-(
> Something is definitely fishy with the visibility of SELECT here. 

Without "for update" I see a tuple in session2 from before session1 began.
After both complete, the net result is correct (id is incremented by 2).
This is very interesting, unfortunately I must leave Internet access until 
monday since my daughter called me home, and mail is so dead slow,
that I did not even receive my last mails yet :-(


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2001-03-30 16:56:17
Subject: Re: RC2 schedualed for Tomorrow evening ...
Previous:From: Bruce MomjianDate: 2001-03-30 15:52:52
Subject: Re: [SQL] Re: pg_dump potential bug -UNIQUE INDEX on PG_SHADOW Dont!! HELP

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group