On Fri, Dec 14, 2018 at 11:32 AM Rushabh Lathia
wrote:
>
> While looking code further around this, I realized that we need
> similar kind of fix for bitmap as well as index only scan as well.
>
I think if we want to move forward with this patch, we need to first
investigate the deadlock hazard me
While looking code further around this, I realized that we need
similar kind of fix for bitmap as well as index only scan as well.
Here is the patch, which does similar fix for bitmap and indexonly
scans.
Thanks,
On Fri, Nov 23, 2018 at 6:47 PM Rushabh Lathia
wrote:
>
>
> On Fri, Nov 23, 2018
On Fri, Nov 23, 2018 at 3:33 AM David Rowley
wrote:
> On Thu, 22 Nov 2018 at 22:33, Rushabh Lathia
> wrote:
> > CREATE TABLE foo (x int primary key);
> > INSERT INTO foo VALUES (1), (2), (3), (4), (5);
> >
> > CREATE OR REPLACE FUNCTION f1(a int) RETURNS int
> > AS $$
> > BEGIN
> > DELETE FROM
David Rowley writes:
> On Thu, 22 Nov 2018 at 22:33, Rushabh Lathia wrote:
>> Now, to fix this issue either we need to hold proper lock before reaching
>> to ExecInitIndexScan() or teach ExecInitIndexScan() to take AccessShareLock
>> on the scan coming from CMD_DELETE.
> I'd say the following co
On Thu, 22 Nov 2018 at 22:33, Rushabh Lathia wrote:
> CREATE TABLE foo (x int primary key);
> INSERT INTO foo VALUES (1), (2), (3), (4), (5);
>
> CREATE OR REPLACE FUNCTION f1(a int) RETURNS int
> AS $$
> BEGIN
> DELETE FROM foo where x = a;
> return 0;
> END;
> $$ LANGUAGE plpgsql;
>
> postgres
Hi,
Commit b04aeb0a053e7cf7faad89f7d47844d8ba0dc839 add assertions that we hold
some relevant lock during relation open as opening a relation with no lock
at all is unsafe;
With above commit below test case is failing and hitting the newly added
Assert().
Test case:
===
CREATE TABLE foo
