Re: BUG #11732: Non-serializable outcomes under serializable isolation
От | Peter Bailis |
---|---|
Тема | Re: BUG #11732: Non-serializable outcomes under serializable isolation |
Дата | |
Msg-id | CALgH=-M-o7T8FqNgKh8TENqtThRx7CPEtW3fJztTZaa4Ox9WCA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #11732: Non-serializable outcomes under serializable isolation (Kevin Grittner <kgrittn@ymail.com>) |
Ответы |
Re: BUG #11732: Non-serializable outcomes under serializable isolation
|
Список | pgsql-bugs |
I spent some more time playing with the PL/pgSQL-based workload. I find that I'm still able to trigger the behavior if I: a.) Drop the primary key column entirely from the table and the stored procedure (basically, just perform read-then-insert on the single "key" column). b.) Change the "key" column from a varchar to an integer. I started to wonder if this suggests an issue with page-level locking on a non-indexed column. So, I recompiled PostgreSQL 9.3.5 with blocksizes of 32768 (./configure --with-blocksize=32) and 1024 and didn't have any discernible effect (was able to reproduce). I also directly modified the configure script to allow a 1MB blocksize and was again able to reproduce the behavior. Have you had any luck reproducing this behavior? Thanks, Peter On Tue, Oct 21, 2014 at 11:28 AM, Kevin Grittner <kgrittn@ymail.com> wrote: > Peter Bailis <pbailis@cs.berkeley.edu> wrote: > > > I just re-ran the workload with max_pred_locks_per_transaction set > > (in postgresql.conf) to each of 1280, 12800, and 128000 and > > observed the duplicate behavior under each setting. > Thanks for checking! > > Looking into it.... > > -- > Kevin Grittner > EDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
В списке pgsql-bugs по дате отправления: