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
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)
"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 s
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.
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
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
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
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..
