On 30 August 2012 22:42, Jeff Lake <admin@michiganwxsystem.com> wrote:
> Lack even basic manners??
> I have been at installing this for 3 days
> manners/patience is gone!!
That's not my problem. Projecting your frustration on this mailing
list isn't cool, and, along with your poor description of the problem,
is a sure way to get your bug report ignored.
> lets see MySql works , Oracle works...
> install PostgreSQL
> nope it don't work, either using Command line, php, for the hell of I tried
> perl
> nope all fail, all segmentation fault so what would that say to you???
> PostgreSQL is the failing point !!
No, as I've already pointed out, the failing point is php/pgsql.so's
questionable assumption, an assumption that was made elsewhere within
php, since this same issue is known to affect MySQL installations.
Just because your MySQL installation isn't affected doesn't mean all
other MySQL installations are not. For example, it might just be that
your MySQL client library wasn't built with OpenSSL support.
> 9.1.5
> 8.1.23
> 8.4
>
> all give the same EXACT Error ...
>
> oh yes .. libpq.so.5 is in the ldd for pgsql.so
That doesn't mean anything on its own. What is the path to libpq.so.*?
Can't you paste the output? Does pg_config output confirm that the
server version associated with this libpq shared object is in fact the
version that you believe it to be? If all of that is consistent with
having a libpq version that actually has commit
4e816286533dd34c10b368487d4079595a3e1418, can you produce a GDB back
trace of the php process, by doing the same thing as the complainant
that posted to the php bug tracker? The process is documented here:
https://bugs.php.net/bugs-generating-backtrace.php
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services