-
Notifications
You must be signed in to change notification settings - Fork 157
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
Out of shared memory error while dropping fhir schema using ibm cloud databases for postgresql #1631
Comments
To address this, set max_locks_per_transaction = 128. Update PostgreSQL container and performance guide. In addition, there were two attempts to drop the same sequence object, causing the second attempt to fail. For PostgreSQL, any statement failure like this causes the transaction to fail. Making the drop sequence idempotent addresses this for PostgreSQL:
|
the first time I ran it, it failed due to a dropped connect:
However, it succeeded in 45 seconds upon retry. |
I feel like I must have done something wrong when I confirmed this one earlier. I am now consistently hitting this error for our IBM Cloud Databases for Postgresql instance. |
To work around this, the schema tool now drops all the FK constraints in the schema first in a separate transaction. This reduces the amount of locking that PostgreSQL has to do when it comes to dropping the tables, and therefore avoids the shared memory error (which is actually a running out of locks error). |
I confirmed this on IBM Cloud Databases for PostgreSQL by creating a new service instance (with the default settings), then creating the schema with:
deploying a new schema with:
and finally dropping it with:
The drop completed successfully in ~213 seconds.
|
Describe the bug
To Reproduce
Steps to reproduce the behavior:
Expected behavior
it drops the schema
Additional context
After discussing with @punktilious, the issue is that we try to drop the whole schema in a single transaction.
Instead, to properly delete a schema, we should write logic that reads from the FHIR_ADMIN.VERSION_HISTORY table and intelligently drops the schema objects in batches.
The text was updated successfully, but these errors were encountered: