Can someone review this thread and determine if this patch is needed?
Thanks.
---------------------------------------------------------------------------
On Fri, Dec 22, 2017 at 04:58:47PM +0530, Dilip Kumar wrote:
> On Mon, Dec 11, 2017 at 4:33 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
>
> On Mon, Dec 11, 2017 at 3:54 PM, tushar <tushar.ah...@enterprisedb.com>
> wrote:
>
> Hi,
>
> While testing something , I found that even after rule has dropped
> not
> able to insert data and in an another scenario , there is a Crash/
>
> Please refer this scenario's -
>
> 1) Rows not inserted after dropping the RULE
>
> postgres=# create table e(n int);
> CREATE TABLE
> postgres=# create rule e1 as on insert to e do instead nothing;
> CREATE RULE
> postgres=# create function e11(n int) returns int as $$ begin insert
> into e values(10); return 1; end; $$ language 'plpgsql';
> CREATE FUNCTION
> postgres=# select e11(1);
> e11
> -----
> 1
> (1 row)
>
> postgres=# select e11(1);
> e11
> -----
> 1
> (1 row)
>
> postgres=# select * from e; => Expected , due to the RULE enforced
> n
> ---
> (0 rows)
>
>
> postgres=# drop rule e1 on e; ==>Drop the rule
> DROP RULE
>
> postgres=# select e11(1); =>again try to insert into table
> e11
> -----
> 1
> (1 row)
>
> postgres=# select * from e; =>This time , value should be inserted
> but
> still showing 0 row.
> n
> ---
> (0 rows)
>
>
> I think this is becuase we are not invalidating the plan cache if rule is
> dropped. You can reproduce same with prepared statements.
>
>
> 2)Server crash (one time)
>
> postgres=# create table en(n int);
> CREATE TABLE
> postgres=# create function en1(n int) returns int as $$ begin insert
> into en values(10); return 1; end; $$ language 'plpgsql';
> CREATE FUNCTION
> postgres=#
> postgres=# select en1(1);
> en1
> -----
> 1
> (1 row)
>
> postgres=# select * from en;
> n
> ----
> 10
> (1 row)
>
> postgres=# create rule en11 as on insert to en do instead nothing;
> CREATE RULE
> postgres=# select en1(1);
> ostgres=# select en1(1);
> TRAP: FailedAssertion("!(!stmt->mod_stmt)", File: "pl_exec.c", Line:
> 3721)
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
>
>
> I have looked into this crash, seems like below assert in
> exec_stmt_execsql
> is not correct
>
> case SPI_OK_REWRITTEN:
>
> Assert(!stmt->mod_stmt);
>
> In this issue first time execution of select en1(1); statement, stmt->
> mod_stmt is set to true for the insert query inside the function. Then
> before next execution we have created the rule "create rule en11 as on
> insert to en do instead nothing;". Because of this nothing will be
> executed and output will be SPI_OK_REWRITTEN. But we are asserting that
> stmt->mod_stmt should be false (which were set to true in first
> execution).
>
>
> IMHO if the query is rewritten, then this assert is not valid. I have attached
> a patch which removes this assert.
>
> --
> Regards,
> Dilip Kumar
> EnterpriseDB: http://www.enterprisedb.com
> diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c
> index dd575e7..9b85df8 100644
> --- a/src/pl/plpgsql/src/pl_exec.c
> +++ b/src/pl/plpgsql/src/pl_exec.c
> @@ -3727,8 +3727,6 @@ exec_stmt_execsql(PLpgSQL_execstate *estate,
> break;
>
> case SPI_OK_REWRITTEN:
> - Assert(!stmt->mod_stmt);
> -
> /*
> * The command was rewritten into another kind of
> command. It's
> * not clear what FOUND would mean in that case (and
> SPI doesn't
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
