Re: BUG #17923: Excessive warnings of collation version mismatch in logs
От | Peter Eisentraut |
---|---|
Тема | Re: BUG #17923: Excessive warnings of collation version mismatch in logs |
Дата | |
Msg-id | 6c53254e-3e03-aa73-6007-bc67397fd507@enterprisedb.com обсуждение исходный текст |
Ответ на | BUG #17923: Excessive warnings of collation version mismatch in logs (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
AW: BUG #17923: Excessive warnings of collation version mismatch in logs
|
Список | pgsql-bugs |
On 07.05.23 12:13, PG Bug reporting form wrote: > 1. Why isn't it sufficient to report this message only at server startup ? > The messages are sent to psql too, but only when logging into one of these > mostly unused databases, so it is not observed in a regular routine. Each database is separate. The server doesn't look at each database on startup. This is only done when you connect to a given database. > 2. Why is this message reported for databases with no objects or similar > cases? When you connect to a database, the server doesn't scan all objects in the database to see if they might be affected. That would be too slow. If you have no objects in the database, you can just run the provided REFRESH command to make the warning go away. > 3. Is there a real collation change in glibc 2.37 or is it only a version > number mismatch with changes only in other parts of the library? We don't know, because glibc isn't reliable at telling us about it. So we take the safe course. > 4. Could the version information be shown in \l output of psql? That's a valid idea. > 5. Wouldn't it make sense to automatically update the collation version > number of such databases (without any collation-related objects) at server > startup? See #2. We are not going to start scanning each database on each connection to check whether it might be empty.
В списке pgsql-bugs по дате отправления: