Greetings,

Was just playing with 8.2beta1 and importing some data from MySQL and
found something rather annoying. Not *100%* sure the best way to deal
with this, if there even is a way, but...

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'.
psql:/home/sfrost/school/cs750/reality/dump-anonymized.postgres.sql:262:
WARNING: nonstandard use of escape in a string literal
LINE 1: ...9999999999',0,',9:9:999'),(99999,'000000000000' ,0,'XXXX XXXX...
^
HINT: Use the escape string syntax for escapes, e.g., E'\r\n'.
INSERT 0 20795
cs750=#

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. It's possible this was because of network lag and the
server had already processed the request but I'm not sure that was the
only reason. I know I held down ctrl-c for quite a while during the
spew of messages...

Anyhow, don't know if there's really a good solution but it'd be nice
to only get one warning, or one of a given type, or something, and to
respond to cancel requests (if there was an issue there). Sorry this
is more from a user's perspective, I havn't got time atm to go digging
through the code. I'd be curious about implementing a possible
error-aggregation system for reporting on large sets like this but
that might be overkill anyway.

Thanks,

Stephen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFFeLprzgMPqB3kigRAkZ+AKCUnWtPxDUWdTomLlZiiK VR4Qbn3wCfUggM
zWgr1dIQzq054RL64bBAKmk=
=y3rL
-----END PGP SIGNATURE-----

> Anyhow, don't know if there's really a good solution but it'd be nice
> to only get one warning, or one of a given type, or something, and to

Except that one warning would not be accurate, because the warning is
per tuple. How is postgresql going to know that the warning applies to
the same set of data but just a different tuple?


> respond to cancel requests (if there was an issue there). Sorry this
> is more from a user's perspective, I havn't got time atm to go digging
> through the code. I'd be curious about implementing a possible
> error-aggregation system for reporting on large sets like this but
> that might be overkill anyway.

You could dial down client_min_messages, set it to ERROR, then you won't
see warnings

Sincerely,

Joshua D. Drake


>
> Thanks,
>
> Stephen


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

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

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