I wrote:
> (I seem to recall seeing a similar report once before, but I can't find
> it in the archives right now.)
I found what I think is the bug I was remembering:
http://archives.postgresql.org/pgsql-bugs/2007-05/msg00074.php
but unfortunately it's not much help since we never did resolve
what
Christine Desmuke writes:
> [postg...@zu ~]$ /usr/local/pgsql/bin/psql -U nobody
> psql: [postg...@zu ~]$
Wait a minute ... I just looked closer at your sample there. That shows
that psql *is* able to output to stderr, because it was able to print
its own name. So we've been barking up the wron
Christine Desmuke writes:
> [postg...@zu ~]$ /usr/local/pgsql/bin/psql -U nobody
> psql: [postg...@zu ~]$
> [That is, the expected error from psql about the nonexistent user is
> swallowed.]
Try the above under strace, and see what it shows happening to the
writes to stderr (they should be very
Alban Hertroys wrote:
On 7 Aug 2009, at 4:02, Christine Desmuke wrote:
If so, isn't it just the output of stderr getting lost here? What
shell are you using?
Yes, it looks like stderr is lost. I'm running bash, and there is
nothing odd in .bash_profile
Any ideas?
I have to admit I'm ru
On 7 Aug 2009, at 4:02, Christine Desmuke wrote:
If so, isn't it just the output of stderr getting lost here? What
shell are you using?
Yes, it looks like stderr is lost. I'm running bash, and there is
nothing odd in .bash_profile
Any ideas?
I have to admit I'm running out, this seems
Alban Hertroys wrote:
On 31 Jul 2009, at 3:25, Christine Desmuke wrote:
Samples from the regression.diffs:
*** ./expected/boolean.out Fri Jun 1 18:40:19 2007
--- ./results/boolean.out Thu Jul 30 19:16:33 2009
***
*** 75,83
(1 row)
SELECT ' tru e '::text::boolea
On 31 Jul 2009, at 3:25, Christine Desmuke wrote:
Samples from the regression.diffs:
*** ./expected/boolean.out Fri Jun 1 18:40:19 2007
--- ./results/boolean.out Thu Jul 30 19:16:33 2009
***
*** 75,83
(1 row)
SELECT ' tru e '::text::boolean AS invalid;-- err
Tom Lane wrote:
> Christine Desmuke writes:
>> Tom Lane wrote:
>>> Years ago I saw roughly similar symptoms when SELinux decided postgres
>>> shouldn't be allowed to write to /dev/tty.
>
>> Thanks for the suggestion. It is not SELinux (SELinux status:
disabled), but _something_ is preventing pos
Christine Desmuke writes:
> Tom Lane wrote:
>> Years ago I saw roughly similar symptoms when SELinux decided postgres
>> shouldn't be allowed to write to /dev/tty.
> Thanks for the suggestion. It is not SELinux (SELinux status: disabled),
> but _something_ is preventing postgres (both the existi
Tom Lane wrote:
Christine Desmuke writes:
I'm trying to install 8.3.7, but can't get past make check.
CentOS release 4.7 (Final), with an existing install of 8.3.1 running as
a warm standby
...
It looks in every case like the ERROR (and also HINT lines) lines are
causing the failures, but I'
Christine Desmuke writes:
> I'm trying to install 8.3.7, but can't get past make check.
> CentOS release 4.7 (Final), with an existing install of 8.3.1 running as
> a warm standby
> ...
> It looks in every case like the ERROR (and also HINT lines) lines are
> causing the failures, but I'm not su
I'm trying to install 8.3.7, but can't get past make check.
CentOS release 4.7 (Final), with an existing install of 8.3.1 running as
a warm standby
$ eval ./configure `pg_config --configure`
$ gmake
== All of PostgreSQL successfully made. Ready to install.
$ gmake check
Everything looks ok un
12 matches
Mail list logo
