Re: Database-level collation version tracking

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Database-level collation version tracking
Date: 2022-02-09 16:12:41
Message-ID: 15999c47-a252-6fd8-0e38-5570daa94fe5@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2022-02-09 16:15:11 Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
Previous Message Laurenz Albe 2022-02-09 16:06:08 Re: [PATCH] Add reloption for views to enable RLS