Re: WIP patch: Collation support - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: WIP patch: Collation support
Date
Msg-id 87zlm8fbav.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: WIP patch: Collation support  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: WIP patch: Collation support  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Re: WIP patch: Collation support  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:

> Well, I proposed disallowing using a different collation than the source
> database, except for using template0 as the source. That's pretty limited, but
> is trivial to implement and still let's you have databases with different
> collations in the same cluster.

+     if (strcmp(dbtemplate, "template0") != 0 &&
+         (strcmp(lc_collate, src_collation) || strcmp(lc_ctype, src_ctype)))
+         ereport(NOTICE,
+                 (errmsg("database \"%s\" needs to be reindexed manually (REINDEX DATABASE)",
+                         dbname)));        
+ 

This isn't what you described but I think I prefer it this way as just a
warning not an error. I can easily imagine cases where the admin knows there
are either no indexes or no data in their database or where they're perfectly
happy to reindex. A flat prohibition seems annoying.

That said it's worth noting that this would tie our hands with proposals like
retail vacuum which risk database corruption if they fail to refind an index
pointer for a tuple...

Incidentally it seems like the warning should actually explain *why* it needs
to be reindexed manually and perhaps what the consequences are until it is.

AFAIK we can't easily connect to the new database and do some fiddling with
it, can we? If we could we could check if there are any non-empty indexes
which depend on the collation and only print the warning if we find any (and
even mark them invalid).

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication
support!


pgsql-hackers by date:

Previous
From: "Pavel Stehule"
Date:
Subject: stored procedure obfuscation - proposal
Next
From: Heikki Linnakangas
Date:
Subject: Re: Subtransaction commits and Hot Standby