Re: BEFORE trigger can cause undetected partition constraint violation

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Amit Langote <amitlangote09(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BEFORE trigger can cause undetected partition constraint violation
Date: 2017-06-02 01:36:25
Message-ID: CA+TgmoZA4NeVQ=cFb4LTAqvgH8+CYHoUo_USU3Jb4OC0cDcJjQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 1, 2017 at 6:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Without having checked the code, I imagine the reason for this is
> that BEFORE triggers are fired after tuple routing occurs.

Yep.

> Re-ordering that seems problematic, because what if you have different
> triggers on different partitions? We'd have to forbid that, probably
> by saying that only the parent table's BEFORE ROW triggers are fired,
> but that seems not very nice.

The parent hasn't got any triggers; that's forbidden.

> The alternative is to forbid BEFORE triggers on partitions to alter
> the routing result, probably by rechecking the partition constraint
> after trigger firing.

That's what we need to do. Until we do tuple routing, we don't know
which partition we're addressing, so we don't know which triggers
we're firing. So the only way to prevent this is to recheck. Which I
think is supposed to work already, but apparently doesn't.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-06-02 01:38:41 Re: logical replication busy-waiting on a lock
Previous Message Robert Haas 2017-06-02 01:33:32 Re: logical replication and PANIC during shutdown checkpoint in publisher