Re: BUG #11732: Non-serializable outcomes under serializable isolation - Mailing list pgsql-bugs

From Peter Bailis
Subject Re: BUG #11732: Non-serializable outcomes under serializable isolation
Date
Msg-id CALgH=-M-o7T8FqNgKh8TENqtThRx7CPEtW3fJztTZaa4Ox9WCA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #11732: Non-serializable outcomes under serializable isolation  (Kevin Grittner <kgrittn@ymail.com>)
Responses Re: BUG #11732: Non-serializable outcomes under serializable isolation  (Kevin Grittner <kgrittn@ymail.com>)
List 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 by date:

Previous
From: Krystian Bigaj
Date:
Subject: Re: BUG #11805: Missing SetServiceStatus call during service shutdown in pg_ctl (Windows only)
Next
From: Alvaro Herrera
Date:
Subject: Re: ltree::text not immutable?