[00:37] <mwhudson> amurray: hmm
[00:37] <mwhudson> amurray: i think we need some input from postgres-maintaining people
[00:39] <mwhudson> amurray: like, we _could_ rebuild all postgres indices on every glibc update
[00:39] <mwhudson> but my instinct is that this would be considered overkill
[00:39] <mwhudson> amurray: at the other end, we could keep track of which locales change collation between glibc version pairs and only rebuild indices that us the affected collations
[00:40] <mwhudson> but that sounds like a fair bit of engineering
[00:40] <amurray> yeah and more chance for causing trouble too if it goes wrong - we should only do it if we are sure that *not* doing so would likely break stuff
[00:44] <mwhudson> "Oof. Haven’t thought about this a lot but feels like static linking might be the way to go for prod." <- someone who does not understand how this works
[00:44] <mwhudson> (pretty sure static linking does not embed the locale collation tables into the binary...)
[04:46] <tjaalton> RAOF: basically no support at all, at least proactive kind when a stable patch breaks the dkms build..
[04:48] <tjaalton> i mean we can't automatically test the dkms during kernel sru cycles
[04:49] <RAOF> So we probably don't need to do any testing of the glibc update wrt amdpro, then: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1951033
[04:51] <tjaalton> hmm
[04:52] <tjaalton> in this case it might be nice to check :)
[04:55] <tjaalton> or ask them to test