Обсуждение: Unwanted debug messages

Hello, everybuddy.
     I'm trying to get started with psycopg2. I'm working on a Windows 7
box.

I've installed the package
psycopg2-2.5.1.win32-py2.6-pg9.2.4-release.exe found in the site
http://www.stickpeople.com/projects/python/win-psycopg/. I can import it
and connect to a database, but when I run my scripts on the command-line
(both, standard and Cygwin) I get unwanted messages printed to stderr.

For example:

     conn = psycopg2.connect(host="42.42.42.42", port=5432,
database="myDB", user="myUser", password="********")
     if conn is None:
         sys.exit("Connection failed")
     print "Connection successful"

Prints the following:

     DEBUG:  CommitTransaction
     DEBUG:  name: unnamed; blockState:       STARTED; state: INPROGR,
xid/subid/cid: 0/1/0, nestlvl: 1, children:
     Connection successful

I've been unable to turn those messages off. I searched in Google but
couldn't find anything relevant, and I also tried changing the config of
the standard logging module, in case some of that was being used, but
still to no avail. I have also tried installing psycopg2 on a Debian 6
VirtualBox, by means of aptitude install python-psycopg2, and got
version 2.2.1 and it does the exact same thing, both running the
connect() function in a script from bash and in the python interpreter
(Python 2.6.6).

Does anybody know how to prevent this messages?

Thanks in advance!

     Wences

PS: Also asked here:

http://stackoverflow.com/questions/17980967/using-psycopg2-on-windows-i-get-unwanted-debug-messages/17991891?noredirect=1#_=_

    but still nothing...

On 05/08/13 14:05, Wenceslao Grillo wrote:

>     conn = psycopg2.connect(host="42.42.42.42", port=5432,
> database="myDB", user="myUser", password="********")
>     if conn is None:
>         sys.exit("Connection failed")
>     print "Connection successful"
>
> Prints the following:
>
>     DEBUG:  CommitTransaction
>     DEBUG:  name: unnamed; blockState:       STARTED; state: INPROGR,
> xid/subid/cid: 0/1/0, nestlvl: 1, children:
>     Connection successful

Those messages are from Postgres itself.  The second one is a DEBUG3
message in the module backend/access/transam/xact.c.  I'd look at the
logging settings in your postgresql.conf.

Joe

  Hello Joe,
thanks for your prompt reply. You are right, I changed the value of
client_min_messages in the postgresql.conf file to "error" and the
messages stopped appearing.
Do you know of any way to prevent those messages from showing in the
console even if the server sends them? It's not in every server that I
will have that level of privilege.
Thanks again:

     Wences

PS: If you don't mind, I would like to copy your reply, with due
attribution to my question at Stack Overflow, so it might also help others.

On 05/08/2013 15:40, Joe Abbate wrote:
> On 05/08/13 14:05, Wenceslao Grillo wrote:
>
>>      conn = psycopg2.connect(host="42.42.42.42", port=5432,
>> database="myDB", user="myUser", password="********")
>>      if conn is None:
>>          sys.exit("Connection failed")
>>      print "Connection successful"
>>
>> Prints the following:
>>
>>      DEBUG:  CommitTransaction
>>      DEBUG:  name: unnamed; blockState:       STARTED; state: INPROGR,
>> xid/subid/cid: 0/1/0, nestlvl: 1, children:
>>      Connection successful
> Those messages are from Postgres itself.  The second one is a DEBUG3
> message in the module backend/access/transam/xact.c.  I'd look at the
> logging settings in your postgresql.conf.
>
> Joe
>
>

Hola Wences,

On 06/08/13 09:05, Wenceslao Grillo wrote:
> thanks for your prompt reply. You are right, I changed the value of
> client_min_messages in the postgresql.conf file to "error" and the
> messages stopped appearing.
> Do you know of any way to prevent those messages from showing in the
> console even if the server sends them? It's not in every server that I
> will have that level of privilege.

I think you should check log_destination in postgresql.conf.

> Thanks again:
>
>     Wences
>
> PS: If you don't mind, I would like to copy your reply, with due
> attribution to my question at Stack Overflow, so it might also help others.

I've answered your question on SO myself :-)

Saludos,


Joe (otro porteño)

On 08/06/2013 06:25 AM, Joe Abbate wrote:
> Hola Wences,
>
> On 06/08/13 09:05, Wenceslao Grillo wrote:
>> thanks for your prompt reply. You are right, I changed the value of
>> client_min_messages in the postgresql.conf file to "error" and the
>> messages stopped appearing.
>> Do you know of any way to prevent those messages from showing in the
>> console even if the server sends them? It's not in every server that I
>> will have that level of privilege.
>
> I think you should check log_destination in postgresql.conf.

That would change the destination of the messages coming from
log_min_messages and still would require that the OP had privileges on
the server. As far as I know it up to the client to deal with
client_min_messages and I do not think psycopg2 has a way of throttling
that.


>
>> Thanks again:
>>
>>      Wences
>>
>> PS: If you don't mind, I would like to copy your reply, with due
>> attribution to my question at Stack Overflow, so it might also help others.
>
> I've answered your question on SO myself :-)
>
> Saludos,
>
>
> Joe (otro porteño)
>
>


--
Adrian Klaver
adrian.klaver@gmail.com

Hello Adrian,

On 06/08/13 09:34, Adrian Klaver wrote:
> On 08/06/2013 06:25 AM, Joe Abbate wrote:
>> I think you should check log_destination in postgresql.conf.
>
> That would change the destination of the messages coming from
> log_min_messages and still would require that the OP had privileges on
> the server. As far as I know it up to the client to deal with
> client_min_messages and I do not think psycopg2 has a way of throttling
> that.

You're right. However, if I'm not mistaken, if a PG admin has (for some
weird reason) set log_min_messages to some obnoxious setting, I think
it's still possible for a user to do a SET log_min_messages='warning' to
suppress them (and this should be doable from psycopg--if desired).

Furthermore, Wences' set-up seems unusual: from psql, if I set
log_min_messages='debug3' the messages don't go to my process' stderr
(which is supposedly the default), and psql prevents me from changing
log_destination.  It appears like he started postgres from the command
line and the server is sending the output to the parent process.

Joe

On 06/08/2013 10:55, Joe Abbate wrote:
>
> Furthermore, Wences' set-up seems unusual: from psql, if I set
> log_min_messages='debug3' the messages don't go to my process' stderr
> (which is supposedly the default), and psql prevents me from changing
> log_destination.  It appears like he started postgres from the command
> line and the server is sending the output to the parent process.
>
> Joe
>
>
Hola, Joe,

I don't think it's such an unusual setup: One box is running PostgreSQL
and my Python script is in another box, connecting to it (and getting
all the unwanted messages). Because right now I'm using a development
postgres box, I can log in to it and use psql but then I don't get those
messages. The messages show up on my screen, on my terminal when I run
my Python script. And I know that the debug messages are going to stderr
because if I say:
     ./my_script.py 2>/dev/null
I get all the prints that I put in my code and none of the debug
messages. But I miss the messages from uncaught exceptions and the like,
that also go to stderr.

Regards:

     Wences

PS: It had to happen. Two porteños, and chatting in English over the
Internet. Why are all the good lists and forums in English and the
Spanish speaking ones so full of rubbish?!

  Thanks Adrian. Well, I guess I should file a feature request with the
psycopg2 team then... because all the work-arounds I can think of for
this problem are really ugly...
Cheers:

     Wences


On 06/08/2013 10:34, Adrian Klaver wrote:
> On 08/06/2013 06:25 AM, Joe Abbate wrote:
>> Hola Wences,
>>
>> On 06/08/13 09:05, Wenceslao Grillo wrote:
>>> thanks for your prompt reply. You are right, I changed the value of
>>> client_min_messages in the postgresql.conf file to "error" and the
>>> messages stopped appearing.
>>> Do you know of any way to prevent those messages from showing in the
>>> console even if the server sends them? It's not in every server that I
>>> will have that level of privilege.
>>
>> I think you should check log_destination in postgresql.conf.
>
> That would change the destination of the messages coming from
> log_min_messages and still would require that the OP had privileges on
> the server. As far as I know it up to the client to deal with
> client_min_messages and I do not think psycopg2 has a way of
> throttling that.
>
>
>>
>>> Thanks again:
>>>
>>>      Wences
>>>
>>> PS: If you don't mind, I would like to copy your reply, with due
>>> attribution to my question at Stack Overflow, so it might also help
>>> others.
>>
>> I've answered your question on SO myself :-)
>>
>> Saludos,
>>
>>
>> Joe (otro porteño)
>>
>>
>
>

Wences,

On 06/08/13 10:35, Wenceslao Grillo wrote:
> I don't think it's such an unusual setup: One box is running PostgreSQL
> and my Python script is in another box, connecting to it (and getting
> all the unwanted messages). Because right now I'm using a development
> postgres box, I can log in to it and use psql but then I don't get those
> messages. The messages show up on my screen, on my terminal when I run
> my Python script. And I know that the debug messages are going to stderr
> because if I say:
>     ./my_script.py 2>/dev/null
> I get all the prints that I put in my code and none of the debug
> messages. But I miss the messages from uncaught exceptions and the like,
> that also go to stderr.

I'm afraid there's still something different in your environment.  I
edited my postgresql.conf to change log_min_messages to debug3,
restarted it and then ran the following:

$ cat test.py
import sys
import psycopg2
conn = psycopg2.connect(database="jma")
if conn is None:
    sys.exit("Connection failed")
print "Connection successful"
$ python test.py
Connection successful

The debug messages end up in
/var/log/postgresql/postgresql-9.1-main.log, e.g.,

2013-08-06 11:56:14 EDT DEBUG:  CommitTransaction
2013-08-06 11:56:14 EDT DEBUG:  name: unnamed; blockState:
STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
2013-08-06 11:56:14 EDT DEBUG:  shmem_exit(0): 8 callbacks to make
2013-08-06 11:56:14 EDT DEBUG:  proc_exit(0): 2 callbacks to make
2013-08-06 11:56:14 EDT DEBUG:  exit(0)

but never in my front-end process.  I believe that would only happen if
I had started postgres from the command line, i.e., invoking the
'postgres' executable directly instead of using pg_ctl to start it in
the background (or as a service on Windows).

Saludos,

Joe

  Oh! I see what you mean... There's definetly room for that kind of
thing in that server... I'll check.



On 06/08/2013 13:10, Joe Abbate wrote:
> Wences,
>
> On 06/08/13 10:35, Wenceslao Grillo wrote:
>> I don't think it's such an unusual setup: One box is running PostgreSQL
>> and my Python script is in another box, connecting to it (and getting
>> all the unwanted messages). Because right now I'm using a development
>> postgres box, I can log in to it and use psql but then I don't get those
>> messages. The messages show up on my screen, on my terminal when I run
>> my Python script. And I know that the debug messages are going to stderr
>> because if I say:
>>      ./my_script.py 2>/dev/null
>> I get all the prints that I put in my code and none of the debug
>> messages. But I miss the messages from uncaught exceptions and the like,
>> that also go to stderr.
> I'm afraid there's still something different in your environment.  I
> edited my postgresql.conf to change log_min_messages to debug3,
> restarted it and then ran the following:
>
> $ cat test.py
> import sys
> import psycopg2
> conn = psycopg2.connect(database="jma")
> if conn is None:
>      sys.exit("Connection failed")
> print "Connection successful"
> $ python test.py
> Connection successful
>
> The debug messages end up in
> /var/log/postgresql/postgresql-9.1-main.log, e.g.,
>
> 2013-08-06 11:56:14 EDT DEBUG:  CommitTransaction
> 2013-08-06 11:56:14 EDT DEBUG:  name: unnamed; blockState:
> STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
> 2013-08-06 11:56:14 EDT DEBUG:  shmem_exit(0): 8 callbacks to make
> 2013-08-06 11:56:14 EDT DEBUG:  proc_exit(0): 2 callbacks to make
> 2013-08-06 11:56:14 EDT DEBUG:  exit(0)
>
> but never in my front-end process.  I believe that would only happen if
> I had started postgres from the command line, i.e., invoking the
> 'postgres' executable directly instead of using pg_ctl to start it in
> the background (or as a service on Windows).
>
> Saludos,
>
> Joe
>
>

On 08/06/2013 09:10 AM, Joe Abbate wrote:
> Wences,
>
> On 06/08/13 10:35, Wenceslao Grillo wrote:
>> I don't think it's such an unusual setup: One box is running PostgreSQL
>> and my Python script is in another box, connecting to it (and getting
>> all the unwanted messages). Because right now I'm using a development
>> postgres box, I can log in to it and use psql but then I don't get those
>> messages. The messages show up on my screen, on my terminal when I run
>> my Python script. And I know that the debug messages are going to stderr
>> because if I say:
>>      ./my_script.py 2>/dev/null
>> I get all the prints that I put in my code and none of the debug
>> messages. But I miss the messages from uncaught exceptions and the like,
>> that also go to stderr.
>
> I'm afraid there's still something different in your environment.  I
> edited my postgresql.conf to change log_min_messages to debug3,
> restarted it and then ran the following:


The difference is you are working with log_min_messages which controls
what goes to the log file and Wenceslao is working with
client_min_messages which controls what goes to the client.

>
>
> Joe
>
>


--
Adrian Klaver
adrian.klaver@gmail.com