Skip to content

Fix PostgreSQL data persistence#387

Merged
DougReeder merged 1 commit into
Hubs-Foundation:developmentfrom
Exairnous:fix-pgdata-persistence
Sep 16, 2025
Merged

Fix PostgreSQL data persistence#387
DougReeder merged 1 commit into
Hubs-Foundation:developmentfrom
Exairnous:fix-pgdata-persistence

Conversation

@Exairnous
Copy link
Copy Markdown
Member

@Exairnous Exairnous commented Sep 10, 2025

What?

Returns the mountPath for the postgresql-data volume back to it's original value and adds the PGDATA environment variable to the container to specify that the PostgreSQL data be stored in a further subfolder.

Why?

Changing the mountPath doesn't actually change where the data is written, instead it causes Docker to create an anonymous volume at the default path that is discarded when the container/pod is deleted (which loses all the data).

Using the PGDATA environment variable to specify that the PostgreSQL data be stored in a further subfolder should continue to avoid the issue of a lost+found folder being created somewhere PostgreSQL doesn't like it.

Examples

N/A

How to test

  1. Delete your instance, e.g. kubectl delete -f hcce.yaml.
  2. Redeploy your instance with the changes from this PR.
  3. Add some data to your instance.
  4. Delete your deployment/pods and redeploy your instance.
  5. See that your data is still there (previously these steps would have resulted in your data being lost).

Note: if you want to preserve your old data you should back it up first with the backup scripts from PR #382

Documentation of functionality

This fixes a bug in the current behavior, so no documentation change is needed.

Limitations

This will need to be updated in the future because future versions of PostgreSQL expect the data to be stored in version specific folders.

Alternatives considered

None.

Open questions

None.

Additional details or related context

PR #363

References:
https://www.linode.com/community/questions/22421/why-is-postgres-data-deleted-when-pod-restarted-on-kubernetes
https://datageek.blog/2020/06/17/disappearing-data-in-postgresql/
https://stackoverflow.com/questions/58069267/postgres-running-on-kubernetes-looses-data-upon-pod-recreation-or-cluster-reboot
docker-library/postgres#263 (comment)
https://hub.docker.com/_/postgres#pgdata
https://github.com/docker-library/docs/blob/master/postgres/README.md
https://github.com/docker-library/postgres/blob/e2a43025b1acedac60ddfad3678ed5da1a09fd79/12/alpine3.21/Dockerfile
https://github.com/docker-library/postgres/blob/master/18/alpine3.22/Dockerfile

What:
Returns the mountPath for the postgresql-data volume back to it's original value and adds the PGDATA environment variable to the container to specify that the PostgreSQL data be stored in a further subfolder.

Why:
Changing the mountPath doesn't actually change where the data is written, instead it causes Docker to create an anonymous volume at the default path that is discarded when the container/pod is deleted (which loses all the data).

Using the PGDATA environment variable to specify that the PostgreSQL data be stored in a further subfolder should continue to avoid the issue of a lost+found folder being created somewhere PostgreSQL doesn't like it.

Note:
This will need to be updated in the future because future versions of PostgreSQL expect the data to be stored in version specific folders.
Copy link
Copy Markdown
Member

@DougReeder DougReeder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change looks correct.

I'd like to test it on my instance before we merge it, but my cluster now uses an external database.

@jua360
Copy link
Copy Markdown

jua360 commented Sep 16, 2025

Using my CE instance as a test case I along with Imaginer tested the data persistence of this pull request as defined in the PR and it performed as intended.

@DougReeder DougReeder merged commit 0094006 into Hubs-Foundation:development Sep 16, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants