Re: [BUGS] Prepared Statement Name Truncation

2012-11-17 Thread Tom Lane
Phil Sorber writes: > 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 tab

Re: [GENERAL] [BUGS] Prepared Statement Name Truncation

2012-11-17 Thread Tom Lane
"Greg Sabino Mullane" writes: >> If it's a postgres bug, what is the fix? Make the identifier max size >> longer? > I'd also be in favor of this, in addition to upgrading from a NOTICE. Increasing NAMEDATALEN has been discussed, and rejected, before. It is very very far from being a free change

Re: [BUGS] Prepared Statement Name Truncation

2012-11-17 Thread Gavin Flower
On 18/11/12 17:10, Phil Sorber wrote: On Nov 17, 2012 11:06 PM, "Gavin Flower" mailto:gavinflo...@archidevsys.co.nz>> wrote: > > On 18/11/12 16:49, Greg Sabino Mullane wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: RIPEMD160 >> >> >>> NOTICE: identifier >>> "this_is_a_really_long_i

Re: [BUGS] Prepared Statement Name Truncation

2012-11-17 Thread Phil Sorber
On Nov 17, 2012 11:06 PM, "Gavin Flower" wrote: > > On 18/11/12 16:49, Greg Sabino Mullane wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: RIPEMD160 >> >> >>> NOTICE: identifier >>> "this_is_a_really_long_identifier_for_a_prepared_statement_name_ok" >>> will be truncated to >>> "this_is_

Re: [BUGS] Prepared Statement Name Truncation

2012-11-17 Thread Gavin Flower
On 18/11/12 16:49, Greg Sabino Mullane wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 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 ... The ORM

Re: [BUGS] Prepared Statement Name Truncation

2012-11-17 Thread Gavin Flower
On 18/11/12 15:46, Stephen Frost wrote: * Phil Sorber (p...@omniti.com) wrote: In addition it actually works! Only until the ORM tries to create two tables that are identical except for the last few characters.. So I am sharing this with the list to see what people think. Is this a configurat

Re: [BUGS] Prepared Statement Name Truncation

2012-11-17 Thread Greg Sabino Mullane
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > 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 ... > The ORM could use a shorter identifier, but it

Re: [BUGS] Prepared Statement Name Truncation

2012-11-17 Thread Stephen Frost
* Phil Sorber (p...@omniti.com) wrote: > In addition it actually works! Only until the ORM tries to create two tables that are identical except for the last few characters.. > So I am sharing this with the list to see what people think. Is this a > configuration bug? An ORM bug? A postgres bug? A

[BUGS] Prepared Statement Name Truncation

2012-11-17 Thread Phil Sorber
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

Re: [BUGS] BUG #7667: Segmentation fault

2012-11-17 Thread Euler Taveira
On 17-11-2012 07:03, Jacek Domagalski wrote: [keep the list CC'ed] > Scenario to produce error. > > 1. OS - Windows 7 x64 PL, Regional settings in regional.jpg > 2. Installation of postgres-server (postgresql-9.2.1-1-windows-x64.exe) with > default settings > 3. DB scheme in up.backup > 4. Quer