deps: update postgres docker tag to v16

[eclipse-apoapsis-bot]

This PR contains the following updates:

Package	Update	Change
postgres	major	14 -> 16

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot.

[mnonnenmacher]

This will break any existing local databases as PostgreSQL cannot read the data directory of previous major versions. I want to add documentation for manual migration of the database before merging this, so I'm blocking it for now.

[mmurto]

This will break any existing local databases as PostgreSQL cannot read the data directory of previous major versions. I want to add documentation for manual migration of the database before merging this, so I'm blocking it for now.

I think a good solution to this migration problem would be to rather create a set of test data and include the necessary scripts to automatically seed the compose database with this. It would also help in E2E testing, if we want to go there at some point.

[mnonnenmacher]

This will break any existing local databases as PostgreSQL cannot read the data directory of previous major versions. I want to add documentation for manual migration of the database before merging this, so I'm blocking it for now.

I think a good solution to this migration problem would be to rather create a set of test data and include the necessary scripts to automatically seed the compose database with this. It would also help in E2E testing, if we want to go there at some point.

That would be useful but I have lots of scan results for custom tests in my local database that I do not want lose and it's probably the same for others.

[mmurto]

This will break any existing local databases as PostgreSQL cannot read the data directory of previous major versions. I want to add documentation for manual migration of the database before merging this, so I'm blocking it for now.

I think a good solution to this migration problem would be to rather create a set of test data and include the necessary scripts to automatically seed the compose database with this. It would also help in E2E testing, if we want to go there at some point.

That would be useful but I have lots of scan results for custom tests in my local database that I do not want lose and it's probably the same for others.

It works mostly like this, but I'm having some troubles with the admin user not having the admin functionality in the UI after the migration. For this kind of problems (and to make the dev environment generally cleaner) we should probably use a separate database for Keycloak, so don't store all the Keycloak tables in the ort_server database. Feel free to debug, I may come back to this some time.

Dump the database from Postgres 14:

pg_dump -Fc -v -d postgres://postgres:postgres@localhost:5433/ort_server -f mydumpfile.bak

Bring the Compose environment down and destroy the volumes to reset the database:

docker compose down -v

Update the postgres image to 16 in docker-compose.yml and restart the environment:

docker compose up -d

Restore the database from the dump to the updated Postgres:

pg_restore --clean -v -d postgres://postgres:postgres@localhost:5433/ort_server mydumpfile.bak

[mmurto]

Keycloak seems to use public schema and ORT Server the ort_server schema, so this could work by only dumping the ort_server schema and otherwise going through the motions above. So use this for the first command:

pg_dump -Fc -v -d -n ort_server postgres://postgres:postgres@localhost:5433/ort_server -f mydumpfile.bak

[mmurto]

Keycloak seems to use public schema and ORT Server the ort_server schema, so this could work by only dumping the ort_server schema and otherwise going through the motions above. So use this for the first command:

pg_dump -Fc -v -d -n ort_server postgres://postgres:postgres@localhost:5433/ort_server -f mydumpfile.bak

...though then the permissions etc won't migrate, so it doesn't work that way.

Added the migration guide to this PR.

[eclipse-apoapsis-bot]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.

[mnonnenmacher]

@mmurto I have added a commit with a migration guide using basically the commands you provided, I have only changed them to run pg_dump and pg_restore inside the container so that the commands do not have to be installed on the host system.

[sschuberth]

Shouldn't this be a single line according to conventions?

[mnonnenmacher]

This file was not yet migrated to use one sentence per line so I wanted to keep it consistent.

[sschuberth]

Side remark: IMO it's a bit weird that Keycloak does not use a more speaking schema than "public".

[mnonnenmacher]

I noticed that as well but didn't want to change it as part of this PR.

[mmurto]

@mmurto I have added a commit with a migration guide using basically the commands you provided, I have only changed them to run pg_dump and pg_restore inside the container so that the commands do not have to be installed on the host system.

Should we create a DEVELOPMENT.md or something similar? Probably not urgent, but longer term that's probably not information that we need to have prominently visible in readme, as it probably only happens once a year at most and is only relevant for a small group of people.

[mnonnenmacher]

@mmurto I have added a commit with a migration guide using basically the commands you provided, I have only changed them to run pg_dump and pg_restore inside the container so that the commands do not have to be installed on the host system.

Should we create a DEVELOPMENT.md or something similar? Probably not urgent, but longer term that's probably not information that we need to have prominently visible in readme, as it probably only happens once a year at most and is only relevant for a small group of people.

Restructuring of the documentation will happen as part of rendering it as a website, similar to how it's done for ORT. I want to start working on that soon, in the meantime you could provide feedback to #256 if you want.