Feedback-ID: i131946ab:Fastmail
Message-ID: <6c53254e-3e03-aa73-6007-bc67397fd507@enterprisedb.com>
Date: Wed, 10 May 2023 07:30:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.10.1
Subject: Re: BUG #17923: Excessive warnings of collation version mismatch in
 logs
Content-Language: en-US
To: buschmann@nidsa.net, pgsql-bugs@lists.postgresql.org
References: <17923-c791d260d83aa587@postgresql.org>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
In-Reply-To: <17923-c791d260d83aa587@postgresql.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/6c53254e-3e03-aa73-6007-bc67397fd507%40enterprisedb.com>
Precedence: bulk

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.