-
Notifications
You must be signed in to change notification settings - Fork 900
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pg_restore with option --clean
fails
#2556
Comments
@EtienneM |
OK thanks for the clarification. If I don't use the DROP TABLE sensors CASCADE;
DROP TABLE sensor_data;
\! pg_restore --no-owner --no-privileges --host $HOSTNAME --port $PORT --dbname $DB_NAME --user admin /var/lib/postgresql/*pgsql Doing this raises a few errors because some operations are not supported on chunk tables and on hypertables:
Despite these errors, I can see that my data is available in the database but I fear some indexes might be missing. Do you know if these errors are bad or if I can deal with it? |
@EtienneM Sorry for the delay in the reply. My guess is that only foreign key constraints are missing. I don't know if it is related that you restore into the database where the tables were dropped before. Requires an investigation on our side. You might want to create the foreign key constraint on the hypertable manually. |
The thing is that these missing foreign key constraints had been created by TimescaleDB and I have no idea what they are supposed to look like. Some of these missing constraints are defined on chunk tables. Is there a TimescaleDB command to re-create the foreign keys of all the chunk tables? |
@EtienneM TimescaleDB doesn't create any foreign key constraints. So it was manually created by someone in your database (or if you use some ORM, it might be created by it). I see no other way how they appeared in the original database. |
THANK YOU @EtienneM!! If it weren't for this issue, i'd probably still be trying to fix this... I also dumped with -c and tried to restore from that dump, already lost hours searching for a solution. Finally it works, omitting -c solved all issues. |
I encounter similar error due to CONSTRAINT UNIQUE (not FK). |
Hi @danmunteanuevo, thanks for commenting. Are you also still encountering this issue, or did you find a solution? |
Relevant system information:
postgres --version
): postgres (PostgreSQL) 12.4 (Debian 12.4-1.pgdg90+1)\dx
inpsql
): 1.7.4Describe the bug
We fail to restore a backup on the same database the dump was taken.
To Reproduce
Steps to reproduce the behavior:
sensor_data
and make it a hypertablepg_dump --host host.example.com --port 30014 --dbname biniou_5636 --user admin --format c --no-owner --no-privileges --file /tmp/backup.pgsql
psql -c "SELECT timescaledb_pre_restore()" "postgres://admin:..."
pg_restore --host host.example.com --port 30014 --dbname biniou_5636 --user admin --clean --if-exists --no-owner --no-privileges /tmp/backup.pgsql
Expected behavior
The backup should be restored without issue
Actual behavior
The execution of the
pg_restore
command leads to many errors:Additional context
I can see that your documentation (https://docs.timescale.com/latest/using-timescaledb/backup#pg_dump-pg_restore) only mentions the use case of restoring a backup in a fresh and empty database. Hence I'm wondering if our use case is simply not supported, or if we missed an important step. Does any one of you tried what we are trying to achieve?
Note that we currently use this process to restore some PostgreSQL databases (without TimescaleDB) and it works like a charm.
The text was updated successfully, but these errors were encountered: