psql> select version();
PostgreSQL 9.6.1, compiled by Visual C++ build 1800, 64-bit
upgraded lock on the PL table, caused by the RLS policy.
I'm running Postgres 9.6.1 (I think)
Phil Horder
Database Mechanic
-Original Message-
From: rob stone [mailto:floripa...@gmail.com]
Sent: 24 March 2018 11:30
To: HORDER Phil; pgsql-general
Subject: Re: Foreign Key locking / de
Some databases will create a unique index for you when you create a primary key.
Oracle will create one, but only if you haven’t already done that.
Postgres will ALWAYS create a unique index based on the primary key – so you
should never do that as well, or the db will have to maintain two
it;
Phil Horder
Database Mechanic
-Original Message-
From: rob stone [mailto:floripa...@gmail.com]
Sent: 23 March 2018 11:43
To: HORDER Phil; pgsql-general
Subject: Re: Foreign Key locking / deadlock issue v2
Hello Phil,
I've run your sample script on 9.6.5 and 10.3.
T
heck as suggested makes no difference to the demo - the
blocking lock still occurs.
Phil Horder
Database Mechanic
-Original Message-
From: rob stone [mailto:floripa...@gmail.com]
Sent: 22 March 2018 11:11
To: HORDER Phil; Adrian Klaver
Cc: pgsql-general
Subject: Re: Foreign Key loc
OK,
Let's try again, with a full script, and including the bit that makes the
difference…
Hi,
I’m trying to understand why I’m getting a deadlock issue, and how to work
around it.
At base, I think the problem is:
1.Updates to a parent table are creating row level write
Apologies, I committed the heinous crime of not creating a full working demo.
It seems that Row Level Security is involved - I'll post an update with full
code ASAP
Phil Horder
Database Mechanic
Hi,
I'm trying to understand why I'm getting a deadlock issue, and how to work
around it.
At base, I think the problem is:
1. Updates to a parent table are creating row level write locks,
2. updates to a child table set the foreign key value to the parent
table, which are then
