Database-level collation version tracking - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Database-level collation version tracking
Date
Msg-id f0ff3190-29a3-5b39-a179-fa32eee57db6@enterprisedb.com
Whole thread Raw
Responses Re: Database-level collation version tracking  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
This patch adds to database objects the same version tracking that 
collation objects have.  There is a new pg_database column 
datcollversion that stores the version, a new function 
pg_database_collation_actual_version() to get the version from the 
operating system, and a new subcommand ALTER DATABASE ... REFRESH 
COLLATION VERSION.

This was not originally added together with pg_collation.collversion, 
since originally version tracking was only supported for ICU, and ICU on 
a database-level is not currently supported.  But we now have version 
tracking for glibc (since PG13), FreeBSD (since PG14), and Windows 
(since PG13), so this is useful to have now.  And of course ICU on 
database-level is being worked on at the moment as well.

This patch is pretty much complete AFAICT.  One bonus thing would be to 
add a query to the ALTER DATABASE ref page similar to the one on the 
ALTER COLLATION ref page that identifies the objects that are affected 
by outdated collations.  The database version of that might just show 
all collation-using objects or something like that.  Suggestions welcome.

Also, one curious behavior is that if you get to a situation where the 
collation version is mismatched, every time an autovacuum worker 
launches you get the collation version mismatch warning in the log. 
Maybe that's actually correct, but maybe we want to dial it down a bit 
for non-interactive sessions.
Attachment

pgsql-hackers by date:

Previous
From: Andy Fan
Date:
Subject: Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?
Next
From: Fujii Masao
Date:
Subject: Re: Add checkpoint and redo LSN to LogCheckpointEnd log message