Debian Buster is going to cause some reindexing headaches

[tianon]

See https://lists.debian.org/debian-glibc/2019/03/msg00030.html, https://bugs.debian.org/926627, and https://salsa.debian.org/ddp-team/release-notes/commit/ad75c4b for some context.

When upgrading from stretch to buster, the glibc locale data is upgraded.
Specifically, this changes how PostgreSQL sorts data in text indexes.
To avoid corruption, such indexes need to be REINDEXed
immediately after upgrading the locales or
locales-all packages, before putting back the database
into production.

Suggested command: sudo -u postgres reindexdb --all

I'm not entirely sure how we're going to handle this, but it does mean it won't be reasonable for us to simply upgrade the images from Stretch to Buster once Buster is released. 😕 😞

[tianon]

Comparing https://www.postgresql.org/support/versioning/ to https://wiki.debian.org/LTS/, Debian Stretch is officially supported until 2020 with LTS support until June 2022, which gives us coverage for all of 9.x and almost all of 10.x (June to November is the window we're looking at there). PostgreSQL 11 is going to be a little more difficult to manage.

So we need some kind of transition plan for users of PostgreSQL 10 and 11 in place before June 2022.

[tianon]

https://wiki.postgresql.org/wiki/Locale_data_changes is a great link for explaining the problem in more detail 👍

[n-rodriguez]

Hi there!

Why not create new tags like 10-stretch, 10-buster and so on?

Like Docker Redis does :

• https://hub.docker.com/_/redis/?tab=tags&page=1&name=stretch
• https://hub.docker.com/_/redis/?tab=tags&page=1&name=buster

[tianon]

We've been avoiding that because we don't want the added maintenance burden of multiple bases nor do we think that actually provides significant value when weighed against the added confusion for end-users.

Looking at the example of Redis -- if you look at https://github.com/docker-library/redis, you'll see that we only maintain a single base for each version, and so the tagging merely reflects the base that exists. If we were to apply that here, we would add a 10-stretch tag alias, but we would not create 10-buster.

[n-rodriguez]

Hi there! Any news?

[tianon]

Given we haven't found a simpler/better solution, we're going with the "support multiple Debian versions" solution in #852 -- the bare "10" etc aliases on version that are still on Stretch will stay on Stretch until it becomes EOL, at which point we no longer plan to update them (and they'll be dropped from the "supported" list completely, leaving only "10-buster" etc).

[yosifkit]

For reference:

the bare 9, 10, and 11 aliases on version that are still on Stretch will stay on Stretch until it becomes EOL, at which point we no longer plan to update them (and they'll be dropped from the "supported" list completely, leaving only "10-buster" etc).

- #582 (comment)

So postgres:9, postgres:10. and postgres:11 will always be Debian Stretch (and will stop being updated when that version is end of life or Stretch is end of life).

---

Summary: When upgrading from 9 (or 10 or 11) which is based on Debian Stretch to the same version but based on Debian Buster (9-buster), It should be enough to ensure you have a full backup (for safety) and then do a reindexdb --all in the new container.

Very rough untested steps

1. make a postgres backup
2. stop postgres:9 container
3. start new postgres:9-buster container using same data directory
4. run reindexdb --all in the new container (perhaps via docker exec)
5. 🎉