mirror of
https://github.com/postgres/postgres.git
synced 2026-03-10 02:01:23 -04:00
b99dd71705
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. |
||
|---|---|---|
| .. | ||
| initdb | ||
| pg_archivecleanup | ||
| pg_basebackup | ||
| pg_config | ||
| pg_controldata | ||
| pg_ctl | ||
| pg_dump | ||
| pg_resetxlog | ||
| pg_rewind | ||
| pg_test_fsync | ||
| pg_test_timing | ||
| pg_upgrade | ||
| pg_xlogdump | ||
| pgbench | ||
| pgevent | ||
| psql | ||
| scripts | ||
| Makefile | ||