From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | Petr Fedorov <petr(dot)fedorov(at)phystech(dot)edu>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: A row-level trigger on a partitioned table is not created on a sub-partition created later |
Date: | 2019-12-31 19:47:59 |
Message-ID: | 20191231194759.GA24692@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 2019-Dec-27, Alvaro Herrera wrote:
> One thing I just realized is that in next minors' release notes we
> should publish a recipe to fix catalogs for existing databases, unless
> we go for a fix that doesn't require changing the catalogs -- I don't
> know what that would be, though, but maybe it would not be totally
> insane to clone even internal triggers in the cases that matter.
So, the more I thought about this, the more it seemed that marking those
triggers as not internal was the wrong thing to do. So I instead made
it clone the internal triggers that seem to matter. This fixes the
originally reported problem, and passes the test case I propose. Also,
pg_dump continues to work unchanged, and existing database don't need
tweaking (excepting those that might already be missing triggers).
It would be better to fix master afterwards, by adding a
pg_trigger.trgparentid column, which seems like it would be a better
answer going forward.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
0001-Add-failed-test-that-shows-the-issue.patch | text/x-diff | 4.0 KB |
0002-Fix-trigger-cloning.patch | text/x-diff | 2.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Sandeep Thakkar | 2020-01-01 05:26:08 | Re: PostgreSQL Installation Error |
Previous Message | Juan José Santamaría Flecha | 2019-12-31 11:22:30 | Re: pg_upgrade |