"Bojan Jovanovic" <pgbojan@bjovanovic.com> writes:
> We just upgraded to 8.2.4, and noticed that psql does not display error
> messages, e.g.:
> ...
> shp_production=# select * from asdfafsdf;
On my system I compiled 8.2.4 as well, and not only would an
interactive session like yours display no error messages, but psql
even lost its ability to echo messages to the command line:
$ psql db_that_does_not_exist
psql:
$
So I starting adding printf() statements to libpq.so.5 to see what was
going on, and, when I added a printf() to fe-protocol3.c, suddenly
libpq regained its ability to produce error messages! Removing my
printf() then had no further effect; it was simply re-compiling
fe-protocol3.c that must have done the trick. I have had no further
problems.
I note that gcc-4.1 was upgraded on my (Debian unstable) system
between my first having compiled PostgreSQL, and the compilation today
that resulted in a working libpq:
version that broke fe-protocol3 -> 4.1.2-12
version that fixed fe-protocol3 -> 4.1.2-14
Anyone who wishes to dive further into the secrets of "The Libpq Who
Would Print No Error Messages" may examine it here:
http://rhodesmill.org/tmp/libpq.so.5
By placing it in the current directory and running psql with
LD_PRELOAD set, you can see the problem for yourself (assuming that
your system has enough libraries in common that this libpq can resolve
its symbols):
$ LD_PRELOAD=$PWD/libpq.so.5 psql
psql:
$
If anyone decompiles it and determines why its machine code is broken
whereas the machine code produced by my gcc today works, I would be
fascinated to know. I wonder whether libpq engages in dangerous and
undefined C behavior that only works if the compiler happens to be in
the mood, or whether this was a bug in gcc-4.1?
I noted, by the way, that the broken and the working libpq on my
system at this moment both link against the same libraries; so it must
be a difference in libpq itself, not anything beneath it.
--
Brandon Craig Rhodes brandon@rhodesmill.org http://rhodesmill.org/brandon
