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

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas SB
Тема AW: Re: [SQL] possible row locking bug in 7.0.3 & 7.1
Дата
Msg-id 11C1E6749A55D411A9670001FA687963368268@sdexcsrv1.f000.d0188.sd.spardat.at
обсуждение исходный текст
Список 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 :-(

Andreas


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: testing last sanpshot in QNX platform
Следующее
От: Thomas Lockhart
Дата:
Сообщение: Third call for platform testing