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

From Peter Eisentraut
Subject Re: Database-level collation version tracking
Date
Msg-id 15999c47-a252-6fd8-0e38-5570daa94fe5@enterprisedb.com
Whole thread Raw
In response to Re: Database-level collation version tracking  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Database-level collation version tracking  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
On 08.02.22 13:55, Julien Rouhaud wrote:
> Apart from that I still think that we should check the collation version of the
> source database when creating a new database.  It won't cost much but will give
> the DBA a chance to recreate the indexes before risking invalid index usage.

A question on this:  In essence, this would be putting code into 
createdb() similar to the code in postinit.c:CheckMyDatabase().  But 
what should we make it do and say exactly?

After thinking about this for a bit, I suggest: If the actual collation 
version of the newly created database does not match the recorded 
collation version of the template database, we should error out and make 
the user fix the template database (by reindexing there etc.).

The alternative is to warn, as it does now in postinit.c.  But then the 
phrasing of the message becomes complicated: Should we make the user fix 
the new database or the template database or both?  And if they don't 
fix the template database, they will have the same problem again.  So 
making it a hard failure seems better to me.



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
Next
From: Andrew Dunstan
Date:
Subject: Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints