Re: [BUGS] BUG #3269: PSQL does not display error output
Thanks for the help Tom and others! Nope, definitely did not intentionally redirect the STDERR.. RHEL3 had SELinux. Do you have /usr/sbin/getenforce and if so what does it report? NO SElinux on this box... (don't have getenforce) On the same box I had 7.3.6 for 3 years running flawlessly.. Decided to upgrade (had 8.2.3 running flawlessly on the staging/dev servers, and 8.1.8 on dev servers), since the RPM was not available on the website for RHEL ES 3 (although the dir is there), downloaded the source, compiled, installed (everything went smoothly), changed pg_hba.conf, postgresql.conf and started the application.. Everything works just fine except for this error reporting by psql. If I connect from the remote server (using psql 8.2.3 or 8.1.8), everything works just fine. Also if I connect from that server (using 8.2.4 psql) to a remote 8.2.3 server, the problem exists. All this was obvious from the problem, but just to make it clear that to me it seems to be psql issue.. Also I tried connecting to a remote 7.3.5, but got "FATAL: unsupported frontend protocol" - assume that fine - not that much backwards compatible. I would have provided you with access to the box to test, but unfortunately this is a production server, and the nature of business does not allow me to. Is there any test/anything else that I can do to provide further testing/input to you? Thanks! Regards, bojan On Fri, 11 May 2007, Tom Lane wrote: Bojan Jovanovic <[EMAIL PROTECTED]> writes: How would STDERR get redirected from psql? The usual way, like "psql 2>/dev/null", but if you didn't know that then it's unlikely you did it. I have seen symptoms roughly like this one with really ancient SELinux policies (the first draft of the policy tried to suppress direct writes on /dev/tty from any Postgres executable, IIRC :-(). But I didn't think RHEL3 had SELinux. Do you have /usr/sbin/getenforce and if so what does it report? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #3272: ECPG YE000 error
The following bug has been logged online: Bug reference: 3272 Logged by: Taso Hatzi Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.4 Operating system: Red Hat Enterprise Linux ES release 4 (Nahant Update 5) Description:ECPG YE000 error Details: The host is a Dell 2950 Dual Intel Xeon with 2GB RAM Built 8.2.4 from postgresql-8.2.4-1PGDG.src.rpm Removed all traces of 7.4.16-1.RHEL4 Everything appeared to go OK. The application is multi-threaded. It bombs with a YE000 error when subjected to any sort of work load. Compiled the application on a Fedora Core release 6 (Zod) box running 8.1.8-1.fc6 and pointed it to the 8.2.4 server and it looks Ok. I'm not sure what debug info to collect. It looks to me like a thread isolation problem. Any pointers on how top proceed gladly received. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #3272: ECPG YE000 error
Taso Hatzi wrote: It looks to me like a thread isolation problem. I don't know anything about the RPM packages, but did you use the --enable-thread-safety option wuth configure? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3272: ECPG YE000 error
Heikki Linnakangas wrote: I don't know anything about the RPM packages, but did you use the --enable-thread-safety option wuth configure? The RPM package enables that option. $ pg_config CONFIGURE = '--build=i686-redhat-linux-gnu' '--host=i686-redhat-linux-gnu' '--target=i686-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-rpath' '--with-perl' '--with-python' '--with-tcl' '--with-tclconfig=/usr/lib' '--with-openssl' '--with-pam' '--with-krb5' '--with-includes=/usr/include' '--with-libraries=/usr/lib' '--enable-nls' '--enable-thread-safety' '--sysconfdir=/etc/sysconfig/pgsql' '--datadir=/usr/share/pgsql' '--with-docdir=/usr/share/doc' 'CFLAGS=-O2 -g -pipe -m32 -march=i686 -mtune=pentium4 -I/usr/include/et' 'CPPFLAGS= -I/usr/include/et' 'build_alias=i686-redhat-linux-gnu' 'host_alias=i686-redhat-linux-gnu' 'target_alias=i686-redhat-linux-gnu' ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #3269: PSQL does not display error output
Bojan Jovanovic <[EMAIL PROTECTED]> writes: >> RHEL3 had SELinux. Do you have /usr/sbin/getenforce and if so what does >> it report? > NO SElinux on this box... (don't have getenforce) Strange. Try strace'ing the psql session to see if it's trying to write stderr and if so what happens. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3272: ECPG YE000 error
"Taso Hatzi" <[EMAIL PROTECTED]> writes: > It looks to me like a thread isolation problem. If you have multiple threads accessing the same connection, it's up to *you* to provide interlocking to make sure they don't try to issue concurrent queries; libpq has no internal mutex for that. I believe similar statements hold for ECPG's state. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #3269: PSQL does not display error output
Hi Tom,
Here is the full strace of: echo "select * from sadfasdfas;" | strace psql -U
* *
(no sadfasfaf table..)
execve("/usr/local/bin/psql", ["psql", "-U", "nutriscan_staging",
"shp_staging"], [/* 22 vars */]) = 0
uname({sys="Linux", node="new.mynutriscan.com", ...}) = 0
brk(0) = 0x807b000
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/usr/local/pgsql/lib/tls/i686/mmx/libpq.so.5", O_RDONLY) = -1 ENOENT (No
such file or directory)
stat64("/usr/local/pgsql/lib/tls/i686/mmx", 0xb280) = -1 ENOENT (No such
file or directory)
open("/usr/local/pgsql/lib/tls/i686/libpq.so.5", O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64("/usr/local/pgsql/lib/tls/i686", 0xb280) = -1 ENOENT (No such file
or directory)
open("/usr/local/pgsql/lib/tls/mmx/libpq.so.5", O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64("/usr/local/pgsql/lib/tls/mmx", 0xb280) = -1 ENOENT (No such file or
directory)
open("/usr/local/pgsql/lib/tls/libpq.so.5", O_RDONLY) = -1 ENOENT (No such file
or directory)
stat64("/usr/local/pgsql/lib/tls", 0xb280) = -1 ENOENT (No such file or
directory)
open("/usr/local/pgsql/lib/i686/mmx/libpq.so.5", O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64("/usr/local/pgsql/lib/i686/mmx", 0xb280) = -1 ENOENT (No such file
or directory)
open("/usr/local/pgsql/lib/i686/libpq.so.5", O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64("/usr/local/pgsql/lib/i686", 0xb280) = -1 ENOENT (No such file or
directory)
open("/usr/local/pgsql/lib/mmx/libpq.so.5", O_RDONLY) = -1 ENOENT (No such file
or directory)
stat64("/usr/local/pgsql/lib/mmx", 0xb280) = -1 ENOENT (No such file or
directory)
open("/usr/local/pgsql/lib/libpq.so.5", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\3508\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=112026, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb75ea000
old_mmap(NULL, 93248, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb75d3000
old_mmap(0xb75e9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x16000) = 0xb75e9000
close(3)= 0
open("/usr/local/pgsql/lib/libssl.so.4", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=36840, ...}) = 0
old_mmap(NULL, 36840, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb75ca000
close(3)= 0
open("/lib/libssl.so.4", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\226"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=211908, ...}) = 0
old_mmap(NULL, 212612, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb7596000
old_mmap(0xb75c7000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x31000) = 0xb75c7000
close(3)= 0
open("/usr/local/pgsql/lib/libcrypto.so.4", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("/lib/libcrypto.so.4", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\252"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=972156, ...}) = 0
old_mmap(NULL, 985368, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb74a5000
old_mmap(0xb7581000, 73728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0xdc000) = 0xb7581000
old_mmap(0xb7593000, 10520, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7593000
close(3)= 0
open("/usr/local/pgsql/lib/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/libz.so.1", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\31"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=52584, ...}) = 0
old_mmap(NULL, 55564, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb7497000
old_mmap(0xb74a3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0xb000) = 0xb74a3000
close(3)= 0
open("/usr/local/pgsql/lib/libreadline.so.4", O_RDONLY) = -1 ENOENT (No such
file or directory)
open("/usr/lib/libreadline.so.4", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\257"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=173000, ...}) = 0
old_mmap(NULL, 179412, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb746b000
old_mmap(0xb7492000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x26000) = 0xb7492000
old_mmap(0xb7496000, 3284, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7496000
close(3)= 0
mprotect(0xb000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1
EINVAL (Invalid argument)
mprotect(0xbfff8000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 ENOMEM (Cannot
allocate memory)
mprotect(0xbfffc000, 16384, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 ENOMEM (Cannot
allocate memory)
mprotect(0xbfffe000, 8192, PROT
Re: [BUGS] BUG #3269: PSQL does not display error output
Bojan Jovanovic <[EMAIL PROTECTED]> writes:
> Here is the full strace of: echo "select * from sadfasdfas;" | strace psql -U
> * *
> (no sadfasfaf table..)
Well, it's sending the query as expected:
> read(0, "select * from sadfasdfas;\n", 4096) = 26
> rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
> send(3, "Q\0\0\0\36select * from sadfasdfas;\0", 31, 0) = 31
> rt_sigaction(SIGPIPE, {SIG_DFL}, {SIG_IGN}, 8) = 0
and getting the error response as expected:
> poll([{fd=3, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
> recv(3, "E\0\0\0]SERROR\0C42P01\0Mrelation \"sa"..., 16384, 0) = 100
and making absolutely no effort to write anything on stderr:
> rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
> read(0, "", 4096) = 0
> rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
> send(3, "X\0\0\0\4", 5, 0) = 5
> rt_sigaction(SIGPIPE, {SIG_DFL}, {SIG_IGN}, 8) = 0
> close(3)= 0
> rt_sigaction(SIGPIPE, {SIG_DFL}, {SIG_DFL}, 8) = 0
> exit_group(0) = ?
That's just bizarre. I don't see any way that psql wouldn't try to
print the error, unless libpq is giving it bad information about the
PGresult's status (or maybe an empty error message?). I think maybe
there is something busted about your libpq, though it's hard to think of
something that would only affect error reporting. Did you build with
debug enabled, such that you could step through AcceptResult() in psql
and see what's happening?
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
