Prepared Statement Name Truncation

From: Phil Sorber <phil(at)omniti(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Prepared Statement Name Truncation
Date: 2012-11-18 02:12:44
Message-ID: CADAkt-hGbxM6QXrPDR=f+VV1PEABLf+i8eu71VSR_vBg5r=P=Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-general

An install of ours was having an issue with log files filling up the
disk rather quickly. After looking into it, the log was filling up
with NOTICE's caused by an ORM that was using a very long identifier
as a name for a prepared statement. It was a concatenation of tables
in the query. The server this happened on was 9.0 but here is a
similar NOTICE from 9.2:

postgres=# prepare
this_is_a_really_long_identifier_for_a_prepared_statement_name_ok as
select 1;
NOTICE: identifier
"this_is_a_really_long_identifier_for_a_prepared_statement_name_ok"
will be truncated to
"this_is_a_really_long_identifier_for_a_prepared_statement_name_"
PREPARE

In one file it was doing it 450 lines per second on average.

So I'm not really sure if this is a bug per se, but it's definitely
undesirable behavior. We could turn off logging of NOTICE's, but there
is other info we'd like to have there. The ORM could use a shorter
identifier, but it supports multiple backends and this is probably not
something in their test suite. In addition it actually works!

So I am sharing this with the list to see what people think. Is this a
configuration bug? An ORM bug? A postgres bug? An unfortunate
interaction?

If it's a postgres bug, what is the fix? Make the identifier max size
longer? Set a hard limit and ERROR instead of truncating and NOTICE?
Both? Neither because that would break backward compatibility?

Thanks.

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Stephen Frost 2012-11-18 02:46:46 Re: Prepared Statement Name Truncation
Previous Message igorya.inscriptio 2012-11-17 21:00:36 BUG #7670: BUG #7545: Unresponsive server with error log reporting: "poll() failed: Invalid argument"

Browse pgsql-general by date

  From Date Subject
Next Message Jasen Betts 2012-11-18 02:15:39 Re: Exclusion constraints with time expressions
Previous Message David Johnston 2012-11-18 01:49:07 Re: Difference between varchar and text?