Re: [HACKERS] delta relations in AFTER triggers
| От | Neha Sharma |
|---|---|
| Тема | Re: [HACKERS] delta relations in AFTER triggers |
| Дата | |
| Msg-id | CANiYTQv05RRHEnQQnoFKTguURnz+o53M3Zb6Jwa1XCn8ELMi=g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] delta relations in AFTER triggers (Thomas Munro <thomas.munro@enterprisedb.com>) |
| Ответы |
Re: [HACKERS] delta relations in AFTER triggers
|
| Список | pgsql-hackers |
Hi,
While testing the feature we encountered one more crash,below is the scenario to reproduce.
create table t1 ( a int);
create table t2 ( a int);
insert into t1 values (11),(12),(13);
create or replace function my_trig() returns trigger
language plpgsql as $my_trig$
begin
insert into t2(select a from new_table);
RETURN NEW;
end;
$my_trig$;
create trigger my_trigger
after truncate or update on t1
referencing new table as new_table old table as oldtab
for each statement
execute procedure my_trig();
truncate t1;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
Log file and core dump attached for reference.
On Thu, May 4, 2017 at 3:21 PM, Thomas Munro <thomas.munro@enterprisedb.com> wrote:
On Thu, May 4, 2017 at 9:12 PM, Prabhat Sahu
<prabhat.sahu@enterprisedb.com> wrote:
> I have been testing this for a while and observed a server crash while referencing table column value in a trigger procedure for AFTER DELETE trigger.
>
> -- Steps to reproduce:
> CREATE TABLE t1(c1 int);
> CREATE TABLE t2(cc1 int);
> INSERT INTO t1 VALUES (10);
> INSERT INTO t2 VALUES (10);
>
> CREATE OR REPLACE FUNCTION trig_func() RETURNS trigger AS
> $$ BEGIN
> DELETE FROM t1 WHERE c1 IN (select OLD.cc1 from my_old);
> RETURN OLD;
> END; $$ LANGUAGE PLPGSQL;
>
> CREATE TRIGGER trg1
> AFTER DELETE ON t2
> REFERENCING OLD TABLE AS my_old
> FOR EACH ROW
> EXECUTE PROCEDURE trig_func();
>
> DELETE FROM t2 WHERE cc1 =10;
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
Reproduced here. The stack looks like this:
frame #3: 0x000000010f06f8b0
postgres`ExceptionalCondition(conditionName="!(readptr-> eflags &
0x0002)", errorType="FailedAssertion", fileName="tuplestore.c",
lineNumber=1237) + 128 at assert.c:54
frame #4: 0x000000010f0cbc85
postgres`tuplestore_rescan(state=0x00007ff219840200) + 85 at
tuplestore.c:1237
frame #5: 0x000000010eced9b1
postgres`ExecReScanNamedTuplestoreScan( node=0x00007ff21d007840) + 81
at nodeNamedtuplestorescan.c:197
frame #6: 0x000000010eca46a6
postgres`ExecReScan(node=0x00007ff21d007840) + 822 at execAmi.c:216
frame #7: 0x000000010ece7eca
postgres`ExecNestLoop(node=0x00007ff21d006310) + 538 at
nodeNestloop.c:148
I think the problem is that the tuplestore read pointer hasn't been
opened with the "rewindable" flag. It works for me with the attached.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Regards,
Neha Sharma
Вложения
В списке pgsql-hackers по дате отправления: