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).