More automated upgrade

[idontusenumbers]

Is there any consideration for a more in-place upgrade?

1. Accept the input data directory mount DATA (no NEW or OLD)
2. Install postgres version based on DATA/PG_VERSION
3. Create a new data directory, run initdb
4. Migrate run pg_upgrade
5. If successful
   • Optionally move the old data from DATA to a backup directory
   • Delete contents of DATA
   • Move everything from the new data directory to DATA

[tianon]

I have not considered creating such a thing (and have no plans to do so here), but I don't see any strong technological limitations to doing so if someone wanted to implement the logic. 👍

[theAkito]

What's the goal of this way of upgrading?

It's also not clear how it's supposed to work.

Do we have the old DATA folder and create a second (new) data directly with initdb?
If yes, how is this different from the previous method, except this one being more cumbersome?

[idontusenumbers]

The previous method requires explicitly indicating the version for both the input and the output.

Can you explain what you mean by cumbersome? Seems like this proposal would lead to a solution that is very not cumbersome.

I basically implemented all this in my own postgres main docker image.

[theAkito]

@idontusenumbers

The previous method requires explicitly indicating the version for both the input and the output.

If I understood correctly, step two involves setting the version correctly, which means you need to know a version, anyway, and perhaps adjust it.

The previous method requires explicitly indicating the version for both the input and the output.

Can you explain what you mean by cumbersome? Seems like this proposal would lead to a solution that is very not cumbersome.

I basically implemented all this in my own postgres main docker image.

• Setting PG_VERSION manually. (?)
• Creating second undefined data directoy and explicitly running initdb.
• Confusion with folders. If the upgrade fails, it might not be always clear, which folder is for which version. Sure, you can look into the folder, but if you deal a lot with the folders and also do a lot of shell work, you can get confused, easily. However, when using folders named 9.6 and 13, everything is crystal clear, without any confusion whatsoever.

I basically implemented all this in my own postgres main docker image.

Yes, again cumbersome. This way you basically have to maintain a custom Docker image, when you could use the default from this project, without any extra work. It's inefficient to reinvent the wheel, when you can use an already available solution. This costs time and resources. It's also more error prone to keep a tiny side project maintained than relying on a popular default solution, many people use and therefore test.
I still do not understand where the initdb is coming from exactly. So, how does the custom image know, which version to upgrade to? The PG_VERSION file? Or where does it all come from? If you tell it how to get the version, you already to the same work as creating 2 folders named 9.6 and 13, except the two folders are not as confusing and complicated as this in-place upgrade proposal.

[idontusenumbers]

Trust me, I'm aware of the pain of maintaining my own docker image. I can't believe the postgres upgrade is as bad as it is, necessitating this sort of nonsense. Seems mysql upgrade to 8 is similar pain.

My proposal is to do all the manual work automatically, that's all. The folder confusion is similar with the manual process.

Correct, it uses PG_VERSION file.

[theAkito]

My proposal is to do all the manual work automatically, that's all.

Okay, but that would work with the current way of upgrading, already. Just create the two folders automatically, move data content to 9.6/, etc...

Correct, it uses PG_VERSION file.

So, if I want to upgrade from 9.6 to 13, what version does the PG_VERSION file incorporate?

P.S.:

I already automated the current way of upgrading, but it's an embedded shell script in a bigger application.

[idontusenumbers]

PG_VERSION is the date the version the data is at. Once you upgrade, it reflects the version of postgres you upgraded to. In your example, you would pull the postgres 13 image and it would read the version 9 from the PG_VERSION file. I admit I'm not sure if it would be 9 or 9.6, I don't remember.