[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] PostgreSQL 8.2beta1 w/ VALUES
From:       "Luke Lonergan" <LLonergan () greenplum ! com>
Date:       2006-09-30 18:38:33
Message-ID: 3E37B936B592014B978C4415F90D662D03EA2412 () MI8NYCMAIL06 ! Mi8 ! com
[Download RAW message or body]

That seems right, there won't be a performance impact unless the warnings are issued.

- Luke

Msg is shrt cuz m on ma treo

 -----Original Message-----
From: 	Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent:	Saturday, September 30, 2006 01:48 PM Eastern Standard Time
To:	Stephen Frost
Cc:	pgsql-hackers@postgresql.org
Subject:	Re: [HACKERS] PostgreSQL 8.2beta1 w/ VALUES

Stephen Frost <sfrost@snowman.net> writes:
>   When loading a rather large data set I started getting errors along
>   these lines:
> psql:/home/sfrost/school/cs750/reality/dump-anonymized.postgres.sql:262:
> WARNING:  nonstandard use of escape in a string literal
> LINE 1: ...XXXXXXXXXX 9999,9:9:999'),(99999,'000000000000',0,'XXXXX XXX...
>                                                              ^
> HINT:  Use the escape string syntax for escapes, e.g., E'\r\n'.

>   Which, by themselves, aren't really an issue *except* for the fact
>   that I got an *insane* number of them.  I don't think it was quite one
>   for every row (of which there were 20,795, you'll note) but it was
>   more than enough to drive me insane.  Additionally, cancel requests
>   were ignored.

That's not too surprising because I don't believe there are any
CHECK_FOR_INTERRUPTS calls in the basic lex/parse loop.  That wouldn't
normally be a problem because that phase is pretty quick, but it is a
problem if the system is spitting tons of messages at you.

It seems like a reasonable thing to do would be to add a
CHECK_FOR_INTERRUPTS in elog.c just after sending a notice/warning
message to the client.

Comments?

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

               http://archives.postgresql.org

[prev in list] [next in list] [prev in thread] [next in thread]