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. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
