pgsql: Fix pg_dump/pg_restore to restore event triggers later.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Fix pg_dump/pg_restore to restore event triggers later.
Date: 2020-03-09 18:58:39
Message-ID: E1jBNbr-000183-ND@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Fix pg_dump/pg_restore to restore event triggers later.

Previously, event triggers were restored just after regular triggers
(and FK constraints, which are basically triggers). This is risky
since an event trigger, once installed, could interfere with subsequent
restore commands. Worse, because event triggers don't have any
particular dependencies on any post-data objects, a parallel restore
would consider them eligible to be restored the moment the post-data
phase starts, allowing them to also interfere with restoration of a
whole bunch of objects that would have been restored before them in
a serial restore. There's no way to completely remove the risk of a
misguided event trigger breaking the restore, since if nothing else
it could break other event triggers. But we can certainly push them
to later in the process to minimize the hazard.

To fix, tweak the RestorePass mechanism introduced by commit 3eb9a5e7c
so that event triggers are handled as part of the post-ACL processing
pass (renaming the "REFRESH" pass to "POST_ACL" to reflect its more
general use). This will cause them to restore after everything except
matview refreshes, which seems OK since matview refreshes really ought
to run in the post-restore state of the database. In a parallel
restore, event triggers and matview refreshes might be intermixed,
but that seems all right as well.

Also update the code and comments in pg_dump_sort.c so that its idea
of how things are sorted agrees with what actually happens due to
the RestorePass mechanism. This is mostly cosmetic: it'll affect the
order of objects in a dump's TOC, but not the actual restore order.
But not changing that would be quite confusing to somebody reading
the code.

Back-patch to all supported branches.

Fabrízio de Royes Mello, tweaked a bit by me

Discussion: https://postgr.es/m/CAFcNs+ow1hmFox8P--3GSdtwz-S3Binb6ZmoP6Vk+Xg=K6eZNA@mail.gmail.com

Branch
------
REL9_5_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/0b02476442d56818f9f055b6fbce3a9b83e9b758

Modified Files
--------------
src/bin/pg_dump/pg_backup_archiver.c | 19 ++++++++++---------
src/bin/pg_dump/pg_backup_archiver.h | 16 ++++++++++------
src/bin/pg_dump/pg_dump_sort.c | 18 ++++++++++++++----
3 files changed, 34 insertions(+), 19 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Fujii Masao 2020-03-10 00:42:40 pgsql: Tidy up XLogSource code in xlog.c.
Previous Message Jeff Davis 2020-03-09 18:12:08 pgsql: Introduce LogicalTapeSetExtend().