[00:37] amurray: hmm [00:37] amurray: i think we need some input from postgres-maintaining people [00:39] amurray: like, we _could_ rebuild all postgres indices on every glibc update [00:39] but my instinct is that this would be considered overkill [00:39] 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] but that sounds like a fair bit of engineering [00:40] 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] "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] (pretty sure static linking does not embed the locale collation tables into the binary...) [04:46] RAOF: basically no support at all, at least proactive kind when a stable patch breaks the dkms build.. [04:48] i mean we can't automatically test the dkms during kernel sru cycles [04:49] 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:49] Launchpad bug 1951033 in glibc (Ubuntu) "20.04 SRU" [Undecided, New] [04:51] hmm [04:52] in this case it might be nice to check :) [04:55] or ask them to test === sem2peie- is now known as sem2peie === klebers_ is now known as klebers === nibbon_6 is now known as nibbon_ === guiverc2 is now known as guiverc === genii-core is now known as genii