PostgreSQL collation errors occur when you reference a collation that is not available on your system. This typically happens after OS upgrades, during database migrations, or when using locale settings that are not installed. Check available collations and install missing locales to resolve the issue.
The "collation does not exist" error occurs when PostgreSQL cannot find the specified collation in its catalog. Collations are locale-aware sorting and comparison rules that PostgreSQL uses for string operations. This error means either the collation was never created on your system, the system locale is missing, or there is a version mismatch between PostgreSQL and the operating system's locale database. PostgreSQL relies on the operating system's localization support, so system-level locale configurations directly affect available collations.
Connect to your database and query the available collations:
SELECT collname FROM pg_collation ORDER BY collname;This lists all collations that PostgreSQL recognizes on your system. Look for the collation you're trying to use. If it's not in the list, you need to make it available.
For a more detailed view:
SELECT collname, collencoding, collisvalid
FROM pg_collation
WHERE collencoding IN (-1, 6) -- UTF8
ORDER BY collname;On Linux/Unix, check which locales are installed:
locale -aThis shows all generated locales on your system. If you're looking for en_US.UTF-8 and it's not listed, you need to generate it.
On macOS, use:
locale -a | grep en_USIf the locale doesn't exist, generate it:
# On Debian/Ubuntu
sudo locale-gen en_US.UTF-8
sudo update-locale LANG=en_US.UTF-8
# On RHEL/CentOS/Fedora
sudo localedef -i en_US -f UTF-8 en_US.UTF-8
# Verify it was created
locale -a | grep en_USNote: You need root privileges to generate locales. The specific commands vary by Linux distribution.
After installing the locale on the system, restart the PostgreSQL service:
# On systemd (most modern systems)
sudo systemctl restart postgresql
# On other systems
sudo service postgresql restart
# Or via Docker
docker restart <postgres_container_name>PostgreSQL caches available locales at startup, so you must restart it to pick up newly installed system locales.
After restarting PostgreSQL, verify the collation now appears:
SELECT collname FROM pg_collation WHERE collname = 'en_US.utf8' OR collname = 'en_US.UTF-8';Note: PostgreSQL normalizes collation names, so en_US.UTF-8 may appear as en_US.utf8 in the catalog. You can use either format when creating tables, PostgreSQL will match it correctly.
Once the collation is available, you can now use it:
-- Create a table with a specific collation
CREATE TABLE users (
id SERIAL PRIMARY KEY,
name TEXT COLLATE "en_US.utf8",
email TEXT COLLATE "en_US.utf8"
);
-- Or alter a column
ALTER TABLE users
ALTER COLUMN name TYPE TEXT COLLATE "en_US.utf8";
-- Create a database with a specific collation
CREATE DATABASE mydb
WITH ENCODING 'UTF8'
LC_COLLATE = 'en_US.UTF-8'
LC_CTYPE = 'en_US.UTF-8';The collation is now available and the error should be resolved.
Collation version mismatches can occur after glibc or OS upgrades, where PostgreSQL reports "collation version mismatch" rather than "does not exist." In such cases, refresh collation versions with ALTER DATABASE dbname REFRESH COLLATION VERSION; and reindex affected tables. When migrating databases across systems with different locale configurations, always verify available collations on both source and target systems. PostgreSQL also supports ICU (International Components for Unicode) collations as an alternative to system locales—compile PostgreSQL with --with-icu to enable them. For production deployments, always document required locales in deployment scripts and ensure they're installed before database initialization. Collation selection affects sorting, comparison, and full-text search behavior, so changing collations on existing columns requires careful planning and potential data reindexing.
ERROR: syntax error at end of input
Syntax error at end of input in PostgreSQL
Bind message supplies N parameters but prepared statement requires M
Bind message supplies N parameters but prepared statement requires M in PostgreSQL
Multidimensional arrays must have sub-arrays with matching dimensions
Multidimensional arrays must have sub-arrays with matching dimensions
ERROR: value too long for type character varying
Value too long for type character varying
insufficient columns in unique constraint for partition key
How to fix "insufficient columns in unique constraint for partition key" in PostgreSQL