Disadvantages of backup and recovery

[frg01]

I tried to use dump_all and load_all for backup and recovery, but between backup and recovery I tried to uninstall and reinstall the extension, which made the new train impossible. It seems that the new environment did not add code logic to judge the projects table. Whether the same id already exists in .

There is already data in the table about projects、models....

"1. create dir 
mkdir -p /root/pgml-bak
2.pgml.dump_all
SELECT pgml.dump_all('/root/pgml-bak');
3. drop 
drop extension pgml;
4. create 
create extension pgml; 
5. check projects
select * from pgml.projects;"

"1. pgml.load_all
select pgml.load_all('/root/pgml-bak');

"1.select pgml.load_dataset('diabetes');
select pgml.train(
    project_name => 'Diabetes Regression new',
    task => 'regression',
    relation_name => 'pgml.diabetes',
    y_column_name  => 'target',
    algorithm=> 'kernel_ridge'
);"

INFO:  Snapshotting table "pgml.diabetes", this may take a little while...
ERROR:  duplicate key value violates unique constraint "projects_pkey"
LINE 1: SELECT COUNT(*) FROM information_schema.tables WHERE table_n...
               ^
QUERY:  SELECT COUNT(*) FROM information_schema.tables WHERE table_name = $1 AND table_schema = $2
Time: 32.945 ms

Is the result of my usage considered a bug?

[montanalow]

I believe you would be better served with:

ALTER EXTENSION pgml UPDATE;

Dropping the extension drops all trained models, because those tables are owned by the extension.

[frg01]

I believe you would be better served with:

ALTER EXTENSION pgml UPDATE;

Dropping the extension drops all trained models, because those tables are owned by the extension.

Okay, thanks, so the application scenario of pgml backup and recovery applies to extension upgrades. Is my understanding correct?