The following bug has been logged online:

Bug reference: 1672
Logged by: Gregory L Miller-Kramer
Email address: millerg (AT) contexttech (DOT) com
PostgreSQL version: 8.0.2
Operating system: CentOS 4.0
Description: Postgres 8.0 doesn't return errors.
Details:

To Whom it may concern:
Postgres8 does not return errors for some reason. If you look at the errors
generated on dev or purposely cause an error in psql you will see what I
mean. All errors are being dumped to /opt/pgsql/pgstartup.log. I'm thinking
maybe this is a config option when postgres is built? Or maybe a bug in
Postgres8?

I had originally thought this was fixed by removing the ">> $PGLOG" from the
the postgres startup script and restarting postgres. However, all that did
was dump errors to STDOUT rather than the log file, so it looked to me like
the problem was fixed. However, after I logged out of pgsql, I saw that I
was still getting errors on the console from other people and the apps, etc.
And when I closed my shell, all errors were lost, so I had to put the change
back so that we could at least find the errors in pgstartup.log if we need
them.

When we used 7.4.2 we did not have this issue. The errors would disply in
psql as well as in the web page. We are using Apache, mod_perl, and
apache::ASP...

Thank you,
Greg Miller-Kramer

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

On Mon, May 16, 2005 at 02:16:34PM +0100, Gregory L Miller-Kramer wrote:
In what context?

Please provide an example so we can see exactly what you're talking
about; the bug report doesn't contain enough information to duplicate
the problem.

What's the output of "SHOW client_min_messages;"?

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

"Gregory L Miller-Kramer" <millerg (AT) contexttech (DOT) com> writes:
This report is pretty unclear, but are you complaining that there's
nothing in pgstartup.log? There's not supposed to be; that file only
exists to catch any error messages that might come out before the error
logging mechanism is started up. The default logging arrangement in the
8.0 RPMs is that postmaster log output goes into day-named log files
under /var/lib/pgsql/data/pg_log/. If you don't like that, feel free to
adjust the postgresql.conf parameters that control it.

regards, tom lane

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

http://archives.postgresql.org

On Tue, May 17, 2005 at 05:05:03PM -0400, Gregory L Miller-Kramer wrote:

As I asked in my previous message, what's the output of the following
query?

SHOW client_min_messages;

My first guess is that client_min_messages is set to "fatal" or
"panic", which, although not among the documented settings for
client_min_messages, are allowed and would have the effect you
describe:

test=> SET client_min_messages TO panic;
SET
test=> SELECT misspelled_excol FROM extable;
test=> SET client_min_messages TO notice;
SET
test=> SELECT misspelled_excol FROM extable;
ERROR: column "misspelled_excol" does not exist

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

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

On Wed, May 18, 2005 at 09:11:00AM -0400, Gregory L Miller-Kramer wrote:
Hmmm...is it possible that psql's stderr is redirected? That's
another way I can duplicate what you're seeing:

$ psql test 2> /dev/null
test=> SELECT misspelled_excol FROM extable;
test=>

$ psql test
test=> SELECT misspelled_excol FROM extable;
ERROR: column "misspelled_excol" does not exist
test=>

If psql's stderr isn't explicitly redirected then psql would inherit
the shell's stderr, which might be redirected. What shell are you
using? If it's a Bourne-like shell, what output do you get from
the following?

echo test1
echo test2 >&2

Does your system have lsof or some other utility that shows a
process's file descriptors? If so, what does that utility show
for a running psql that's experiencing the problem?

Do you get output from non-error queries?

If none of this reveals the problem, then it might be useful to see
the output of "\set" and "show all" in psql.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

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

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

Gregory L Miller-Kramer <millerg (AT) contexttech (DOT) com> writes:
[ scratches head... ] It's pretty hard to see why SHOW would display
something but error messages don't get displayed.

However, I still have a sneaking feeling that SELinux is mixed up in
this somehow. Does "/usr/sbin/getenforce" show that enforcement is
active? If so, does "sudo /usr/sbin/setenforce 0" change psql's
behavior?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match