Closed tailhook closed 4 years ago
cfg
is an interesting case. because some configuration may actually be stored in the config file (once implemented). Additionally, you may not want to restore all configuration from a backup, because parts of it might be invalid or undesirable for the new instance. As a point of reference, Postgres does not dump its config with pg_dumpall
. Understandably, server upgrade
needs to preserve config, so we still need an option to dump it, but I'd argue it shouldn't be on by default. Also, it would probably be cleaner to implement DESCRIBE CONFIG
that would emit the necessary config statements directly instead of doing SELECT
and rendering on the client side.
it would probably be cleaner to implement DESCRIBE CONFIG that would emit the necessary config statements directly instead of doing SELECT and rendering on the client side.
Big +1.
Looks like was done in Alpha 4.
Should dump all the databases and all extra metadata stored in the postgres:
cfg
module data and roles/autentication data.Current idea, of how it should work:
SELECT
queries to querycfg
module, and createmetadata.edgeql
file, that containsCONFIGURE
,CREATE ROLE
and similar commandsmetadata.edgeql
and per-database dump into an archive (perhaps.tar
)restore --all
for the whole instance, but each database is checked as in normal restore.