[BUGS] chr() function leads to OOM / killed connection with 8.1, 8.2

2007-07-19 Thread Wiktor Wodecki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

I found something that I believe to be a bug in postgresql handling of
the chr function. This function takes an ascii code and returns the
character.
Now it seems that a value greater than 191 seems to cause trouble with a
backend instance of postgresql. I verified this on postgres 8.1.8, 8.1.9
and 8.2.4. I could not trigger the behaviour with 8.1.3 or 8.1.5. I did
not test other versions.

The effects are:

8.1.8 / 8.1.9:
transport=> select id,msisdn,replace(msisdn, chr(192), 'FF') from
msisdnmap limit 2;
ERROR:  out of memory
DETAIL:  Failed on request of size 17.

The backend process consumes a lot memory and uses up all available CPU
 cycles. The logfile gives OOM statistics. I can provide that if needed.


8.2.4:
dwh=> select replace(customer_id, chr(192), 'FF') from sms_customer limit 1;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>

the logfile says:

2007-07-19 18:07:49 CEST @[5385]LOG:  server process (PID 15351) was
terminated by signal 11
2007-07-19 18:07:49 CEST @[5385]LOG:  terminating any other active
server processes
2007-07-19 18:07:49 CEST [EMAIL PROTECTED]:  the database system is in
recovery mode
2007-07-19 18:07:49 CEST @[5385]LOG:  all server processes terminated;
reinitializing
2007-07-19 18:07:49 CEST @[15353]LOG:  database system was interrupted
at 2007-07-19 12:29:33 CEST
2007-07-19 18:07:49 CEST @[15353]LOG:  checkpoint record is at 9/6552A6C0
2007-07-19 18:07:49 CEST @[15353]LOG:  redo record is at 9/6552A6C0;
undo record is at 0/0; shutdown TRUE
2007-07-19 18:07:49 CEST @[15353]LOG:  next transaction ID: 0/2581; next
OID: 24576
2007-07-19 18:07:49 CEST @[15353]LOG:  next MultiXactId: 1; next
MultiXactOffset: 0
2007-07-19 18:07:49 CEST @[15353]LOG:  database system was not properly
shut down; automatic recovery in progress
2007-07-19 18:07:50 CEST @[15353]LOG:  record with zero length at 9/6552A708
2007-07-19 18:07:50 CEST @[15353]LOG:  redo is not required
2007-07-19 18:07:50 CEST @[15353]LOG:  database system is ready

This behavior is independent of column type, so it should be easy to
reproduce.

Please verify that this is indeed a bug and not a mistake on our side.
Thank you.

- --
Regards,

 Wiktor Wodecki

 net mobile AG, Zollhof 17, 40221 Duesseldorf, Germany
 923B DCF8 070C 9FDD 5E05  9AE3 E923 5A35 182C 9783
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGn45Z6SNaNRgsl4MRAko2AJ9WZN0vUjs9f8IqYDJLzLFsk1szRwCfeTEp
WWaquyaMz0xjMORmfDTRtAA=
=eDv/
-END PGP SIGNATURE-

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [BUGS] chr() function leads to OOM / killed connection with 8.1, 8.2

2007-07-20 Thread Wiktor Wodecki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tom Lane wrote:
> Wiktor Wodecki <[EMAIL PROTECTED]> writes:
>> I found something that I believe to be a bug in postgresql handling of
>> the chr function. This function takes an ascii code and returns the
>> character.
> 
> What database encoding are you testing in?

As Heikki already found out, this is tested on UTF-8.

- --
Regards,

 Wiktor Wodecki

 net mobile AG, Zollhof 17, 40221 Duesseldorf, Germany
 923B DCF8 070C 9FDD 5E05  9AE3 E923 5A35 182C 9783
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGoFhR6SNaNRgsl4MRAmELAKDBDIAu5jflbFD5691hN78bEZNILwCglBzi
7v+UX+eR1G80EK8foIThNTM=
=e/A5
-END PGP SIGNATURE-

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings