flood in logs

On Fri, Oct 10, 2008 at 12:58:35PM +0200, Sebastian Pawłowski wrote:

have you got any idea where do they come from? and how can i stop them? i
was trying to solve the problem, but with no result
i'm using:
Ubuntu 8.04.1
PostgreSQL 8.3.3 on x86_64-pc-linux-gnu, compiled by GCC cc (GCC) 4.2.3
(Ubuntu 4.2.3-2ubuntu7)
pgbouncer version 1.2.3

additional information:
1. postgresql from ubuntu packages:
$ dpkg -l | grep -E '(libpq|postgres)'
ii libpq-dev 8.3.3-0ubuntu0.8.04 header files for libpq5 (PostgreSQL library)
ii libpq5 8.3.3-0ubuntu0.8.04 PostgreSQL C client library
ii postgresql 8.3.3-0ubuntu0.8.04 object-relational SQL database (latest versi
ii postgresql-8.3 8.3.3-0ubuntu0.8.04 object-relational SQL database, version 8.3
ii postgresql-client 8.3.3-0ubuntu0.8.04 front-end programs for PostgreSQL (latest ve
ii postgresql-client-8.3 8.3.3-0ubuntu0.8.04 front-end programs for PostgreSQL 8.3
ii postgresql-client-common 87 manager for multiple PostgreSQL client versi
ii postgresql-common 87 PostgreSQL database-cluster manager
ii postgresql-contrib 8.3.3-0ubuntu0.8.04 additional facilities for PostgreSQL (latest
ii postgresql-contrib-8.3 8.3.3-0ubuntu0.8.04 additional facilities for PostgreSQL
ii postgresql-doc 8.3.3-0ubuntu0.8.04 documentation for the PostgreSQL database ma
ii postgresql-doc-8.3 8.3.3-0ubuntu0.8.04 documentation for the PostgreSQL database ma
ii postgresql-server-dev-8.3 8.3.3-0ubuntu0.8.04 development files for PostgreSQL 8.3 server-

and, i was able to determine that the problem occurs when i execute 'discard all' query - it is usually being run in our case by pgbouncer:

postgres=# DISCARD ALL;
WARNING: unrecognized node type: 742
DISCARD ALL

on another machine with the same packages - the problem doesn't exist.

what could be the reason behind it?

best regards,

depesz

--
Linkedin: http://www.linkedin.com/in/depesz / blog: http://www.depesz.com/
jid/gtalk: depesz@depesz.com / aim:depeszhdl / skype:depesz_hdl / gg:6749007

hubert depesz lubaczewski <depesz@depesz.com> writes:

postgres=# DISCARD ALL;
WARNING: unrecognized node type: 742
DISCARD ALL

Could we see that with "\set VERBOSITY verbose", please?

regards, tom lane

On Fri, Oct 10, 2008 at 08:24:35AM -0400, Tom Lane wrote:

hubert depesz lubaczewski <depesz@depesz.com> writes:

postgres=# DISCARD ALL;
WARNING: unrecognized node type: 742
DISCARD ALL

Could we see that with "\set VERBOSITY verbose", please?

sure:

postgres=# DISCARD ALL;
WARNING: 01000: unrecognized node type: 742
LOCATION: GetCommandLogLevel, utility.c:2558
DISCARD ALL

Best regards,

depesz

--
Linkedin: http://www.linkedin.com/in/depesz / blog: http://www.depesz.com/
jid/gtalk: depesz@depesz.com / aim:depeszhdl / skype:depesz_hdl / gg:6749007

hubert depesz lubaczewski <depesz@depesz.com> writes:

postgres=# DISCARD ALL;
WARNING: 01000: unrecognized node type: 742
LOCATION: GetCommandLogLevel, utility.c:2558
DISCARD ALL

Mph, so it's an omission in the log_statement code. You must have
log_statement set to mod or ddl on this machine.

regards, tom lane

On Fri, Oct 10, 2008 at 08:42:02AM -0400, Tom Lane wrote:

Mph, so it's an omission in the log_statement code. You must have
log_statement set to mod or ddl on this machine.

yes. it's ddl. and on the machine that doesn't print the warning - it's
"none".

I also checked current (well, from 2 days ago) head - and the problem is
there as well.
so, for now i think it's better to set it to 'none' - and wait for
new release with fix?

best regards,

depesz

--
Linkedin: http://www.linkedin.com/in/depesz / blog: http://www.depesz.com/
jid/gtalk: depesz@depesz.com / aim:depeszhdl / skype:depesz_hdl / gg:6749007

hubert depesz lubaczewski <depesz@depesz.com> writes:

On Fri, Oct 10, 2008 at 08:42:02AM -0400, Tom Lane wrote:

Mph, so it's an omission in the log_statement code. You must have
log_statement set to mod or ddl on this machine.

yes. it's ddl. and on the machine that doesn't print the warning - it's
"none".

Right, we don't bother to call GetCommandLogLevel if the setting is ALL
or NONE, so the oversight isn't exposed by default.

so, for now i think it's better to set it to 'none' - and wait for
new release with fix?

Either that or patch it locally.

I wonder if there are any other omissions in that function...

regards, tom lane