pgAdmin crashes when client_min_messages is set in postgresql.conf

My Deja wrote:

I am trying to get some query trees to appear in the PostgreSQL log
and in order to that I have set
client_min_messages = DEBUG1 in order to use the following settings
debug_print_parse, debug_print_rewritten, or debug_print_plan which
are required for the query tree to show up in the log.

pgAdmin crashes whenever I set that option. I tried a few times and I
am sure of it.
I am using PostgreSQL 7.4 under Cygwin on a Windows 2000 machine, but
I don't think that has any relevance.

I can confirm this problem. Apparently the flood of debug notices will
kill pgAdmin3 after a while.
I'll have a deeper look into this later. Until then, do *not* set these
options in postgresql.conf. Instead, set these options per user (if you
want to observe a user *different* from the one you're using with
pgAdmin3), or set these options in the query tool prior to executing
your queries to inspect.

Regards,
Andreas

My Deja wrote:

I am trying to get some query trees to appear in the PostgreSQL log
and in order to that I have set
client_min_messages = DEBUG1 in order to use the following settings
debug_print_parse, debug_print_rewritten, or debug_print_plan which
are required for the query tree to show up in the log.

pgAdmin crashes whenever I set that option. I tried a few times and I
am sure of it.
I am using PostgreSQL 7.4 under Cygwin on a Windows 2000 machine, but
I don't think that has any relevance.

I reproduced this problem with 7.5 head backend and libpq under win32
and Linux, and found that the problem is pqParseInput3 expecting a
message length >= 30000 only for message types 'T', 'D' and 'd', but not
'N'. In the case tested above, the message will be 49336 bytes long,
causing an endless loop in PQexecFinish because PQgetResult will deliver
the same broken message forever.

The attached patch fixes this. I wonder if there are additional message
types that might be longer?

Regards,
Andreas

Andreas Pflug <pgadmin@pse-consulting.de> writes:

I reproduced this problem with 7.5 head backend and libpq under win32
and Linux, and found that the problem is pqParseInput3 expecting a
message length >= 30000 only for message types 'T', 'D' and 'd', but not
'N'.

Oops. Good catch.

regards, tom lane

Andreas Pflug <pgadmin@pse-consulting.de> writes:

The attached patch fixes this. I wonder if there are additional message
types that might be longer?

We should allow error messages to be long too, I guess, and I also added
NOTIFY messages since there's no telling what people might try to do
with the data payload string once we implement that.

I also fixed the underlying infinite-loop problem.

regards, tom lane

Andreas Pflug wrote:

My Deja wrote:

I am trying to get some query trees to appear in the PostgreSQL log
and in order to that I have set
client_min_messages = DEBUG1 in order to use the following settings
debug_print_parse, debug_print_rewritten, or debug_print_plan which
are required for the query tree to show up in the log.

pgAdmin crashes whenever I set that option. I tried a few times and I
am sure of it.
I am using PostgreSQL 7.4 under Cygwin on a Windows 2000 machine, but
I don't think that has any relevance.

I can confirm this problem. Apparently the flood of debug notices will
kill pgAdmin3 after a while.
I'll have a deeper look into this later. Until then, do *not* set these
options in postgresql.conf. Instead, set these options per user (if you
want to observe a user *different* from the one you're using with
pgAdmin3), or set these options in the query tool prior to executing
your queries to inspect.

How are these options set in the query tool? I can see Explain Options
-Verbose/Analyze on the menu. Which one of these does the trick?

Thanks for the reply

My Deja

My Deja wrote:

How are these options set in the query tool? I can see Explain Options
-Verbose/Analyze on the menu. Which one of these does the trick?

No trick. You type "SET ...." and hit F5.

Regards,
Andreas