From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | BEFORE trigger can cause undetected partition constraint violation |
Date: | 2017-06-01 19:51:12 |
Message-ID: | CA+Tgmoa9DTgeVOqopieV8d1QRpddmP65aCdxyjdYDoEO5pS5KA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I just discovered that a BEFORE trigger can allow data into a
partition that violates the relevant partition constraint. This is
bad.
Here is an example:
rhaas=# create or replace function t() returns trigger as $$begin
new.a := 2; return new; end$$ language plpgsql;
CREATE FUNCTION
rhaas=# create table foo (a int, b text) partition by list (a);
CREATE TABLE
rhaas=# create table foo1 partition of foo for values in (1);
CREATE TABLE
rhaas=# create trigger x before insert on foo1 for each row execute
procedure t();
CREATE TRIGGER
rhaas=# insert into foo values (1, 'hi there');
INSERT 0 1
rhaas=# select tableoid::regclass, * from foo;
tableoid | a | b
----------+---+----------
foo1 | 2 | hi there
(1 row)
That row violates the partition constraint, which requires that a = 1.
You can see that by trying to insert the same row into the partition
directly:
rhaas=# insert into foo1 values (2, 'hi there');
ERROR: new row for relation "foo1" violates partition constraint
DETAIL: Failing row contains (2, hi there).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-06-01 19:56:35 | Re: COPY (query) TO ... doesn't allow parallelism |
Previous Message | Robert Haas | 2017-06-01 19:47:25 | Re: UPDATE of partition key |