pgautoupgrade
Latest changes break standard postgres startup for new DB
Hi, I was just testing this image in my kubernetes cluster, and noticed that this container cannot be used as an initContainer for a new database when using the standard postgres container.
This seems to be a regression, caused by this line, which was introduced in a recent commit.
Is this an intentional change? I'd love to be able to put this as an initcontainer on all my postgres pods just to make sure any updates are handled auto-magically, but this does make things more complicated. Maybe if theres no data in the data directory, then this container should skip doing any work whatsoever, and simply return early?
Thanks in advance!
Steps to reproduce: Create new Kubernetes pod with postgres container + the auto upgrade container as the init container.
The postgres container fails to start because data files were created by the migration from empty to something, but the .conf file was removed
Hi @PaulSonOfLars
The change itself was intentional, but without in mind that people could use the pgautoupgrade container as an initContainer for an empty Postgres instance.
Our entrypoint code needs some addition: Only remove the postgresql.conf if "$PGDATA/PG_VERSION" exists, which should be tracked in a separate variable. In your case, "$PGDATA/PG_VERSION" does not exist, because the entire data directory is empty.
Hi @andyundso - that makes sense.
Fix on my end is easy enough; just stick to the current postgres version. Should last me long enough for now. Thanks again for the cool project!
hi @PaulSonOfLars, would be up to try out a development build where this has been fixed? if so, which PG version do you target and which flavor (alpine / debian), so I could provide a development image?