PostgreSQL plugin v 6.0

Releases
1

Hi everyone,

The PostgreSQL plugin v 6.0 is now available. Together with Orthanc 1.12.3, it allows changing the transaction isolation level from Serializable to ReadCommitted which greatly improves Orthanc ingest performance. Note that this new mode, currently needs to be enabled in the plugin configuration - the Serializable mode remains the default.

Link to the full release notes

As usual, these updates are available:

Enjoy !

Alain

6 Likes
2

The configuration of “TransactionMode” goes in the Orthanc Postgresql config file or the main Orthanc config file?

3

In the PostgreSQL section, as stated in the documentation:
https://orthanc.uclouvain.be/book/plugins/postgresql.html#usage

1 Like
4

Hi Alain,

This is fantastic! Thank you.

I have installed it on 2 systems using the latest orthancteam/orthanc image and have noticed 2 oddities.

We use MaximumStorageSize as well as the Postgres DB plugin.
On 1 system, I updated to the latest image and then needed to change MaximumStorageSize from 100000 to 90000. On restart, Orthanc never finished starting up. When I reverted the change, Orthanc started fine. I repeated this several times always with the same result.

On a second system, we ran out of disk space because the number of scans exceeded the MaximumStorageSize limit. This same system was recycling correctly prior to the Postgres v6 update.

I wonder if there is an issue calculating file size with the new plugin?

Let me know if I can provide any further info to help troubleshoot.

James

5

Hi James,

Indeed, I have reworked the way sizes are computed. Seems we need new integration tests since we have not detected any issues …

I’ll look into it ASAP.

Thanks for the report !

Alain.

1 Like
6

This issue has been fixed in v6.1.

1 Like
7

Thank you Alain!!!

8

Hi everyone,

A bit more information about the PostgreSQL plugin 6.0 and 6.1 that includes an upgrade of the DB schema.

For simple systems with a single Orthanc and “small database”, the process is fully automatic and you should not worry.

However, after applying this upgrade on more complex systems, we are sharing these lessons learned (also available in the book):

When upgrading from revision 1 to revision 2, the upgrade might take quite some time. E.g, we have observed the upgrade taking 17 minutes on a DB with 300.000 studies and 150 millions instances. Orthanc will not respond during the upgrade. Therefore, if you have enabled autohealing (automatic restart in case Orthanc is not responsive), you should likely disable it during the first start with the PostgreSQL plugin v6.0.

Also note that, if you have multiple containers connected to the same DB, all containers will try to acquire an exclusive lock to perform the upgrade of the DB. Only one of them will actually perform the upgrade. Also note that you should not perform a rolling updates of the Orthanc containers when performing a DB upgrade. All Orthanc containers should use the same version of the plugin, the one that is compatible with the current revision.

Therefore, in complex setups, it might be simpler/safer to simply shut-down the Orthanc containers, perform the upgrade manually and then, restart the Orthanc containers with the newest version of the plugin.

To upgrade manually from revision 1 to revision 2, one might run this procedure on the existing DB:

$ wget https://orthanc.uclouvain.be/hg/orthanc-databases/raw-file/default/PostgreSQL/Plugins/SQL/Upgrades/Rev1ToRev2.sql
$ wget https://orthanc.uclouvain.be/hg/orthanc-databases/raw-file/default/PostgreSQL/Plugins/SQL/PrepareIndex.sql
$ psql -U postgres -f Rev1ToRev2.sql
$ psql -U postgres -f PrepareIndex.sql

This procedure is identical to the one performed automatically by Orthanc when it detects that an upgraded is required.

HTH,

Alain.

1 Like
9

I believe I am still having this issue on that latest version.

10

Wow, I guess I’ll leave MySQL behind! Well done!