Thread: Segmentation Fault V 9.1.5
I have looked at darn near every listing for this bug .. "..because curl is loaded before postgresql" << nope didn't work here is my system specs CentOS 5.8 64bit 24gb ram dual i7 php 5.3.16 let yum install 8.1.4 got the error either in a php script or command line deleted 8.1.4, rpm'd 9.1.5 (server, devel, contrib, libs) STILL getting the blasted error !! so whats the fix ??? or do I need to just delete, forget and reuse MySQL ??? -- -Jeff Lake MichiganWxSystem.com AllisonHouse.com TheWeatherCenter.net GRLevelXStuff.com
On 30 August 2012 20:29, Jeff Lake <admin@michiganwxsystem.com> wrote: > I have looked at darn near every listing for this bug .. > "..because curl is loaded before postgresql" << nope didn't work > here is my system specs This must be the worst bug report I've ever seen. I'd give the usual link to "How to Report Bugs Effectively", but it would probably be lost on someone who seems to lack even basic manners. > so whats the fix ??? > or do I need to just delete, forget and reuse MySQL ??? Well, from a little googling I gather that MySQL is also affected by this PHP bug (I am not 100% sure that this is what you're referring to): http://www.logikdev.com/tag/postgresql/ What you don't seem to realise is that this is a mailing list for bugs in the PostgreSQL server. "pgsql" in this context refers to a third-party client library for php, and there's no reason to believe that any of its maintainers are active on this mailing list. That said, why are you trying to use the "ordering" kludge recommended here? https://bugs.php.net/bug.php?id=40926&edit=3 It sounds extremely fragile. Since we apparently now defensively unregister the callbacks associated with this problem, as of this commit from back in 2008: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4e816286533dd34c10b368487d4079595a3e1418 It seems likely that pgsql.so is still linking to some ancient, unsupported libpq, even though you don't think that it is. Are you sure that you're using the libpq distributed with 9.1.5? I don't know much about php, but for Python, you'd do something like: [peter@peterlaptop psycopg2]$ ldd _psycopg.so linux-vdso.so.1 => (0x00007fffbd5ff000) libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007f8753aa4000) libpq.so.5 => /home/peter/pgsql/lib/libpq.so.5 (0x00007f875387c000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8753660000) libc.so.6 => /lib64/libc.so.6 (0x00007f87532a9000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f87530a4000) libutil.so.1 => /lib64/libutil.so.1 (0x00007f8752ea1000) libm.so.6 => /lib64/libm.so.6 (0x00007f8752ba6000) /lib64/ld-linux-x86-64.so.2 (0x0000003cdc400000) Is the libpq shared object you see here (but for pgsql.so) the one that you expect? -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
Lack even basic manners?? I have been at installing this for 3 days manners/patience is gone!! 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 !! 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 -Jeff Lake MichiganWxSystem.com AllisonHouse.com TheWeatherCenter.net GRLevelXStuff.com On 8/30/2012 16:09, Peter Geoghegan wrote: > On 30 August 2012 20:29, Jeff Lake <admin@michiganwxsystem.com> wrote: >> I have looked at darn near every listing for this bug .. >> "..because curl is loaded before postgresql" << nope didn't work >> here is my system specs > This must be the worst bug report I've ever seen. I'd give the usual > link to "How to Report Bugs Effectively", but it would probably be > lost on someone who seems to lack even basic manners. > >> so whats the fix ??? >> or do I need to just delete, forget and reuse MySQL ??? > Well, from a little googling I gather that MySQL is also affected by > this PHP bug (I am not 100% sure that this is what you're referring > to): > > http://www.logikdev.com/tag/postgresql/ > > What you don't seem to realise is that this is a mailing list for bugs > in the PostgreSQL server. "pgsql" in this context refers to a > third-party client library for php, and there's no reason to believe > that any of its maintainers are active on this mailing list. > > That said, why are you trying to use the "ordering" kludge recommended here? > > https://bugs.php.net/bug.php?id=40926&edit=3 > > It sounds extremely fragile. > > Since we apparently now defensively unregister the callbacks > associated with this problem, as of this commit from back in 2008: > > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4e816286533dd34c10b368487d4079595a3e1418 > > It seems likely that pgsql.so is still linking to some ancient, > unsupported libpq, even though you don't think that it is. Are you > sure that you're using the libpq distributed with 9.1.5? I don't know > much about php, but for Python, you'd do something like: > > [peter@peterlaptop psycopg2]$ ldd _psycopg.so > linux-vdso.so.1 => (0x00007fffbd5ff000) > libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007f8753aa4000) > libpq.so.5 => /home/peter/pgsql/lib/libpq.so.5 (0x00007f875387c000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8753660000) > libc.so.6 => /lib64/libc.so.6 (0x00007f87532a9000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007f87530a4000) > libutil.so.1 => /lib64/libutil.so.1 (0x00007f8752ea1000) > libm.so.6 => /lib64/libm.so.6 (0x00007f8752ba6000) > /lib64/ld-linux-x86-64.so.2 (0x0000003cdc400000) > > Is the libpq shared object you see here (but for pgsql.so) the one > that you expect? >
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