On 08/06/2015 04:24 PM, Sophia Wright wrote:
On Fri, Aug 7, 2015 at 2:46 AM, Adrian Klaver mailto:adrian.kla...@aklaver.com>> wrote:
I would also take a look at Alvaro's explanation. My understanding
is that for locking purposes the UNIQUE index is considered sort of
like a FK, as it
On Fri, Aug 7, 2015 at 2:46 AM, Adrian Klaver
wrote:
> I would also take a look at Alvaro's explanation. My understanding is that
> for locking purposes the UNIQUE index is considered sort of like a FK, as
> it could be used as a FK. This then leads to the FOR UPDATE lock, which
> from Table 13.3
On 08/06/2015 09:29 AM, Sophia Wright wrote:
On Fri, Aug 7, 2015 at 1:11 AM, Alvaro Herrera mailto:alvhe...@2ndquadrant.com>> wrote:
Sophia Wright wrote:
> I am seeing some odd locking behaviour when deleting a parent record
> (Postgres 9.4.4).
Somewhere in the triggers for FK c
On Fri, Aug 7, 2015 at 1:11 AM, Alvaro Herrera
wrote:
> Sophia Wright wrote:
> > I am seeing some odd locking behaviour when deleting a parent record
> > (Postgres 9.4.4).
>
> Somewhere in the triggers for FK checks we do "SELECT FOR KEY SHARE" of
> the PK tuples when the FK tuples are altered; a
On 08/06/2015 07:19 AM, Sophia Wright wrote:
I am seeing some odd locking behaviour when deleting a parent record
(Postgres 9.4.4).
Setup:
create table pk_rel (id int primary key);
create table fk_rel (pk_id int references pk_rel (id), x text unique);
insert into pk_rel values (1), (2);
insert i
Sophia Wright wrote:
> I am seeing some odd locking behaviour when deleting a parent record
> (Postgres 9.4.4).
Somewhere in the triggers for FK checks we do "SELECT FOR KEY SHARE" of
the PK tuples when the FK tuples are altered; and conversely when we
remove tuples from the PK side we need to ens
