]> granicus.if.org Git - postgresql/commit
In pg_dump, ensure that view triggers are processed after view rules.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 4 Feb 2016 05:26:10 +0000 (00:26 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 4 Feb 2016 05:26:10 +0000 (00:26 -0500)
commit0ed707e9b7e90891d0eda91b353edf3a69c4b7c4
treee2f926295609c2a6d326b41d0641b425ef669b5d
parentb47b4dbf683f13e6ef09fa0d93aa6e84f3d00819
In pg_dump, ensure that view triggers are processed after view rules.

If a view is split into CREATE TABLE + CREATE RULE to break a circular
dependency, then any triggers on the view must be dumped/reloaded after
the CREATE RULE; else the backend may reject the CREATE TRIGGER because
it's the wrong type of trigger for a plain table.  This works all right
in plain dump/restore because of pg_dump's sorting heuristic that places
triggers after rules.  However, when using parallel restore, the ordering
must be enforced by a dependency --- and we didn't have one.

Fixing this is a mere matter of adding an addObjectDependency() call,
except that we need to be able to find all the triggers belonging to the
view relation, and there was no easy way to do that.  Add fields to
pg_dump's TableInfo struct to remember where the associated TriggerInfo
struct(s) are.

Per bug report from Dennis Kögel.  The failure can be exhibited at least
as far back as 9.1, so back-patch to all supported branches.
src/bin/pg_dump/pg_dump.c
src/bin/pg_dump/pg_dump.h
src/bin/pg_dump/pg_dump_sort.c