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
remove_assert_in_rewritequery.patch
Description: Binary data
