On 30 August 2012 22:42, Jeff Lake <ad...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
