Keep cache statement names within PostgreSQL's 63-byte limit

[aiboupeter]

PostgreSQL silently truncates prepared statement names to NAMEDATALEN - 1 (63 bytes) — the statement hash table is keyed with HASH_STRINGS at NAMEDATALEN, so only the first 63 bytes of a name are compared (pgsql-bugs discussion; the application is expected to avoid it).

The default cache_statement names (ecto_<op>_<source>_<n>, ecto_insert_all_<source>) exceed that for long table names, so two sources that only differ after the 63rd byte map to one server-side statement while Postgrex caches them under distinct client names. On one connection:

1. insert into business_workplace_attendance_leave_comp_rest_minutes — prepares ecto_insert_business_workplace_attendance_leave_comp_rest_minutes_0 (server stores it as ecto_insert_business_workplace_attendance_leave_comp_rest_minut)
2. insert into business_workplace_attendance_leave_comp_rest_minutes_event_logs — a different client name, so Postgrex closes+parses ecto_insert_…_event_logs_0, which the server also truncates to the same 63 bytes → silently replaces the statement from step 1
3. insert into the first table again — client cache hit, so it binds straight away:

   ** (Postgrex.Error) ERROR 08P01 (protocol_violation) bind message supplies 8 parameters,
   but prepared statement "ecto_insert_business_workplace_attendance_leave_comp_rest_minutes_0" requires 5
   

   08P01 isn't one of the codes that evict the client cache, so every later write to that table on that connection fails the same way until it reconnects.

This is what we hit in production; the new integration test (integration_test/pg/prepare_test.exs) reproduces it on master and passes with this change.

Change

Ecto.Adapters.SQL.cache_statement_name/3 caps the generated name at 63 bytes. Names that already fit are returned byte-for-byte unchanged, so the vast majority of applications see no difference. Longer names keep a (UTF-8 safe) prefix of the source and append :erlang.phash2/2 of the full source in base 36, e.g.

ecto_insert_business_workplace_attendance_leave_comp_1YNQTIL_0
ecto_insert_business_workplace_attendance_leave_comp_r_AFUHH7_0

The cap is applied in the shared SQL layer rather than only in the Postgres adapter: MySQL/TDS don't have the limit, but shorter names are harmless there and it keeps one code path.

Tests

• test/ecto/adapters/sql_test.exs — unit tests for the helper (unchanged short names, ≤ 63 bytes, distinct for colliding sources, no split multibyte characters).
• integration_test/pg/prepare_test.exs — two TEMP tables sharing a 51-byte prefix, insert A → B → A → B on one sandboxed connection. Fails on master with the 08P01 above, passes with the fix.
• mix test: 694 tests, 0 failures. ECTO_ADAPTER=pg mix test: 504 tests, 0 failures (PostgreSQL 18.6 local).

🤖 Generated with Claude Code

[josevalim]

Why the phash2 explicit limit?

[josevalim]

No need to trim or add _, it is more important to be faster than have pretty names:

Suggested change

	budget = @max_cache_statement_name_size - byte_size(prefix <> suffix <> hash) - 1
	kept = source |> truncate_utf8(max(budget, 0)) |> String.trim_trailing("_")
	prefix <> kept <> "_" <> hash <> suffix
	budget = @max_cache_statement_name_size - byte_size(prefix <> suffix <> hash)
	kept = source |> truncate_utf8(max(budget, 0))
	prefix <> kept <> hash <> suffix

[josevalim]

Instead of truncating utf8, you can traverse the string and collect the first n-valid ascii bytes. It should be cheaper to implement.