You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Relating to #22, I've recently stumbled over the problem of "how to dump & restore system versioned tables".
My personal preference of pg_dump --format=custom --file=dump.psql my_source_database & pg_restore --format=custom --clean --if-exists --single-transcation -d my_target_database doesn't seem to work with periods, as it doesn't seem to like, how pg_restore directly fiddles with its managed tables.
My current workaround for this is
ensure the periods extension is installed in the target database
create the dump with pg_dump as described above
create a use-list, that excludes the periods extension from the restore: pg_restore --format=custom --list dump.psql | grep -Ev 'EXTENSION - (periods|btree_gist) > dump.use-list
disable periods's event-triggers:
ALTER EVENT TRIGGER periods_drop_protection DISABLE;
ALTER EVENT TRIGGER periods_health_checks DISABLE;
ALTER EVENT TRIGGER periods_rename_following DISABLE;
restore the dump, using the use-list pg_restore --format=custom --single-transaction --clean --if-exists --use-list=dump.use-list -d my_target_database dump.psql
re-enable the event-triggers:
ALTER EVENT TRIGGER periods_drop_protection ENABLE;
ALTER EVENT TRIGGER periods_health_checks ENABLE;
ALTER EVENT TRIGGER periods_rename_following ENABLE;
Is there any other recommended way to dumping and restoring a database with periods?
A couple of notes:
The above workaround probably only works correctly, if the entire database is dumped and restored - or at least all periods employing tables all at once -, as the dumped & restored tables in periods's schema (also called periods by default) contain meta-data for all periods employing tables.
btree_gist needs to be excluded from the use-list too, as it's a dependency of periods and thus can't be dropped and recreated during restore
pg_dump currently only supports including named extensions (-e argument) but doesn't support excluding named extensions, which makes the use of use-lists necessary
The text was updated successfully, but these errors were encountered:
Generally, pg_dump/pg_restore want the target database to be empty. The --clean flag is a blunt workaround that fails quite often, I wouldn't recommend relying on it.
Ok, I understand that --clean may be unsupported because of that. Thanks for the clarification.
What remains then, is the problem described in #22, which happens even without --clean in an otherwise empty database:
$> psql <<EOFCREATE DATABASE test;\c testcreate extension periods cascade;create table test (id int not null primary key);select periods.add_system_time_period('test');select periods.add_system_versioning('test');EOF# [... psql output ...]
$> pg_dump -F c -d test -f test.psql
$> psql -c 'DROP DATABASE test;' -c 'CREATE DATABASE test;'
$> pg_restore -F c -d test --single-transaction test.psql
pg_restore: error: could not execute query: FEHLER: cannot grant DELETE to "public.test_history";history objects are read-only
CONTEXT: PL/pgSQL-Funktion periods.health_checks() Zeile 138 bei RAISE
Command was: REVOKE USAGE ON SCHEMA public FROM PUBLIC;
GRANT ALL ON SCHEMA public TO PUBLIC;
Even after some trying around I yet wasn't able to make pg_restore work, without disabling the event-trigger first.
With my (probably incomplete) patch, this still fails with:
pg_restore: error: could not execute query: FEHLER: cannot revoke SELECT directly from "public.test_history", revoke SELECT from "public.test" instead
CONTEXT: PL/pgSQL-Funktion periods.health_checks() Zeile 255 bei RAISE
Command was: REVOKE ALL ON TABLE public.test_history FROM postgres;
GRANT SELECT ON TABLE public.test_history TO postgres;
Relating to #22, I've recently stumbled over the problem of "how to dump & restore system versioned tables".
My personal preference of
pg_dump --format=custom --file=dump.psql my_source_database
&pg_restore --format=custom --clean --if-exists --single-transcation -d my_target_database
doesn't seem to work with periods, as it doesn't seem to like, howpg_restore
directly fiddles with its managed tables.My current workaround for this is
periods
extension is installed in the target databasepg_dump
as described aboveperiods
extension from the restore:pg_restore --format=custom --list dump.psql | grep -Ev 'EXTENSION - (periods|btree_gist) > dump.use-list
periods
's event-triggers:pg_restore --format=custom --single-transaction --clean --if-exists --use-list=dump.use-list -d my_target_database dump.psql
Is there any other recommended way to dumping and restoring a database with
periods
?A couple of notes:
periods
employing tables all at once -, as the dumped & restored tables inperiods
's schema (also calledperiods
by default) contain meta-data for allperiods
employing tables.btree_gist
needs to be excluded from the use-list too, as it's a dependency ofperiods
and thus can't be dropped and recreated during restorepg_dump
currently only supports including named extensions (-e
argument) but doesn't support excluding named extensions, which makes the use of use-lists necessaryThe text was updated successfully, but these errors were encountered: