Re: [GENERAL] Best free tool for relationship extraction
On 09/13/2012 06:51 PM, Alexander Gataric wrote: I need to determine relationships between several tables. Is there a free tool to extract these from catalog tables? Is there an SQL that also does this? Thanks Alex Sent from my smartphone I'm using http://squirrel-sql.sourceforge.net for those kind of things. Peter -- Peter Hopfgartner web : www.r3-gis.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Getting FATAL: terminating connection due to administrator command
If I do:
SELECT St_Buffer('010120E864F8FFF8FF', 50);
the PostgreSQL process leaves with:
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
The geometry looks like:
POINT(nan nan)
Regards,
Peter Hopfgartner
R3 GIS Srl - GmbH
http://www.r3-gis.com
Tom Lane wrote
Subject: Re: [GENERAL] Getting FATAL: terminating connection due to
administrator command
Date: 15.09.2010 21:34
>"Joshua J. Kugler" writes:
>> On Wednesday 15 September 2010, Peter Hopfgartner elucidated thus:
>>> The server is a rather bare bone server for web mapping, so basically
>>> PostgreSQL/PostGIS, Apache, PHP, Tomcat and little other stuff. The
>>> Dell software was the only which did not come from
>>> CentOS/EPEL/argeo/in-house RPM packages. I've removed the Dell stuff
>>> completely, but the problem is still there.
>
>> Are you running out of memory and getting killed by the OOM killer?
>
>The OOM killer hits its victims with SIGKILL (kill -9), so we can rule
>that out as not matching Peter's symptoms. This is definitely an
>unwanted SIGTERM not SIGKILL.
>
> regards, tom lane
>
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Getting FATAL: terminating connection due to administrator command
"Frank Ch. Eigler" wrote
Subject: Re: Getting FATAL: terminating connection due to administrator command
Date: 16.09.2010 22:59
>
>Peter Hopfgartner writes:
>
>> [...]
>> > >http://sourceware.org/systemtap/examples/process/sigmon.stp
>
>> Now we had the error, but systemtap did not report any SIGTERM. Is
>> it possible to have this error without a SIGTERM being involved? As
>> mentioned in a previous mail, I've modified the script to report
>> SIGTERM sent to any process.
>
>There are some other possibilities. It's possible that the version of
>stap you're using is not expanding signal.send to all possible paths
>of the kernel dispatching signals to your process.
>
>So one might try a few different things:
>
>
(...)
>
># check for another process sending SIGTERM
>probe syscall.kill {
> if (sig == 15) {
>printf("%s[%d] sending %s\n", execname(), pid(), argstr)
>print_ubacktrace()
> }
>}
>
I'm trying this one, currently.
(...)
The sad thing, at the moment, is, that the problem has not been occuring since
days, now. I did not change anything in the setup of the server, only that the
system might be used slightly less, then when it occured, so it is
statistically less likely that it occurs.
>
>(A more modern system compiler & systemtap would give you much better
>variable-value dumping options.)
>
Is there an easy way to install those on a 5.5 system?
>
>- FChE
>
Regards,
Peter
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Getting FATAL: terminating connection due to administrator command
Tom Lane wrote Subject: Re: [GENERAL] Getting FATAL: terminating connection due to administrator command Date: 16.09.2010 18:49 >Peter Hopfgartner writes: >> Tom Lane wrote >>> Peter Hopfgartner writes: >>>> Now we had the error, but systemtap did not report any SIGTERM. Is it >>>> possible to have this error without a SIGTERM being involved? >>> >>> Hmph. I would have said not, but ... >>> >>> What PG version is this exactly? > >> "PostgreSQL 8.4.4 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) >4.1.2 20080704 (Red Hat 4.1.2-48), 64-bit" > >Well, I just took another careful look at the 8.4.x source code. The >only occurrence of that error string is in ProcessInterrupts() when it >sees ProcDiePending set, and so far as I can see ProcDiePending is only >set by the die() signal handler, and in postmaster child processes die() >is only used as a SIGTERM handler. So it's pretty hard to come to the >conclusion that it could be anything else. > >I don't know systemtap well at all, so I can't suggest any reason why >your script might be missing SIGTERM events, but it seems that it must >be. >Perhaps you can find a systemtap expert who can comment on that. > > regards, tom lane > Is there any other way I can attack this issue? Attach GDB? How (I haven't done any serious C programming in this millenium). Peter -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Getting FATAL: terminating connection due to administrator command
Tom Lane wrote Subject: Re: [GENERAL] Getting FATAL: terminating connection due to administrator command Date: 16.09.2010 17:37 >Peter Hopfgartner writes: >> Now we had the error, but systemtap did not report any SIGTERM. Is it >> possible to have this error without a SIGTERM being involved? > >Hmph. I would have said not, but ... > >What PG version is this exactly? > > regards, tom lane > It says: "PostgreSQL 8.4.4 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48), 64-bit" and should be identical to the current Red Hat implementation of postgresql84-server as in RHEL 5.5 Peter -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Getting FATAL: terminating connection due to administrator command
Peter Hopfgartner wrote Subject: Re: [GENERAL] Getting FATAL: terminating connection due to administrator command Date: 16.09.2010 16:56 >Tom Lane wrote > >Subject: Re: [GENERAL] Getting FATAL: terminating connection due to >administrator command > >Date: 15.09.2010 17:40 > > > >>Peter Hopfgartner writes: > >>> Tom Lane wrote > >>>> This is a result of something sending SIGTERM to the backend process. > >> > >>> Can I trace where the SIGTERM comes from? > >> > >>If this is a recent Red-Hat-based release, I think that systemtap could > >>probably be used to determine that. There's a script here that solves > >>a related problem: > >>http://sourceware.org/systemtap/examples/process/sigmon.stp > Now we had the error, but systemtap did not report any SIGTERM. Is it possible to have this error without a SIGTERM being involved? As mentioned in a previous mail, I've modified the script to report SIGTERM sent to any process. Peter -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Getting FATAL: terminating connection due to administrator command
Tom Lane wrote Subject: Re: [GENERAL] Getting FATAL: terminating connection due to administrator command Date: 15.09.2010 17:40 >Peter Hopfgartner writes: >> Tom Lane wrote >>> This is a result of something sending SIGTERM to the backend process. > >> Can I trace where the SIGTERM comes from? > >If this is a recent Red-Hat-based release, I think that systemtap could >probably be used to determine that. There's a script here that solves >a related problem: >http://sourceware.org/systemtap/examples/process/sigmon.stp > Ok, I was able to create the packages with the debug info, adapted the script to report SIGTERM sent so any process, see attachment, tested this sending some SIGTERM and seeing them reported by systemtap. Anyway, currently we are not able to reproduce the problem on the server, magically everything seems to work on this machine. The only changes should be the 2 debug-info packages (kernel-debuginfo-common-2.6.18-194.11.3.el5.x86_64.rpm and kernel-xen-debuginfo-2.6.18-194.11.3.el5.x86_64.rpm). In the same time, the problem appeared twice today on our testing server. This suggests to drop the hardware failure hypothesis. I'm running systemtap on the testing server now, too. > regards, tom lane > sigmon1.stp Description: Binary data -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Getting FATAL: terminating connection due to administrator command
Tom Lane wrote Subject: Re: [GENERAL] Getting FATAL: terminating connection due to administrator command Date: 15.09.2010 17:40 >Peter Hopfgartner writes: >> Tom Lane wrote >>> This is a result of something sending SIGTERM to the backend process. > >> Can I trace where the SIGTERM comes from? > >If this is a recent Red-Hat-based release, I think that systemtap could >probably be used to determine that. There's a script here that solves >a related problem: >http://sourceware.org/systemtap/examples/process/sigmon.stp > > regards, tom lane > As it seems I need to recompile the kernel in order to have the debug infos, http://sourceware.org/systemtap/wiki/SystemTapOnCentOS. Tomorrow I will start the probes. Thanks, Peter -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Getting FATAL: terminating connection due to administrator command
Tom Lane wrote Subject: Re: [GENERAL] Getting FATAL: terminating connection due to administrator command Date: 15.09.2010 16:07 >Peter Hopfgartner writes: >> Since some days we are getting the above message. >> Also in the PostgreSQL logs we get: >> FATAL: terminating connection due to administrator command > >This is a result of something sending SIGTERM to the backend process. > >I have heard reports of "load management" software that SIGTERM's >processes more or less at random whenever it decides the system is >overloaded. If you have any such junkware installed on your server, >try disabling it. The server is a rather bare bone server for web mapping, so basically PostgreSQL/PostGIS, Apache, PHP, Tomcat and little other stuff. The Dell software was the only which did not come from CentOS/EPEL/argeo/in-house RPM packages. I've removed the Dell stuff completely, but the problem is still there. > >> The server is from Dell, Dell's hardware monitoring, OpenManage, says >that the hardware, in particular memory and disk, are ok. > >Never dealt with OpenManage before, but you should cast a wary eye >upon any Dell-specific software on the machine. This behavior is >definitely not normal for Unix systems, so you need to look for >nonstandard software (and what's more, nonstandard software running with >root privileges, else it couldn't SIGTERM postgres processes). > Other informations: disks are costly SAS drives in a RAID 1 array, memory is with ECC. Security level is disabled SELinux is Permissive. The server acts as a XEN host Is it reasonable to restrict the problem to kernel/hardware and/or PostgreSQL/PostGIS itself? Can I trace where the SIGTERM comes from? > regards, tom lane > Regards, Peter -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Getting FATAL: terminating connection due to administrator command
Hi Since some days we are getting the above message. The system is a current CentOS 5.5, x86_64, Postgresql 8.4 as it comes with the packages postgresql84, postgresql84-libs etc. PostGIS is enabled, as it comes from http://www.argeo.org/linux/argeo-el. The error message appears from time to time. The exact same request, coming from a PHP applications, sometimes works, sometimes fails. This happens in different points of our applications, tipically, but not only, when large data portions are queried, as in geometric queries, using PostGIS. The server is only slightly loaded. Also in the PostgreSQL logs we get: FATAL: terminating connection due to administrator command repeated multiple times. The server is from Dell, Dell's hardware monitoring, OpenManage, says that the hardware, in particular memory and disk, are ok. We do have a nearly identical server, with the identical version of PostgreSQL/PostGIS, but that was last updated one or two months ago and which is intensly used as our testing and development server, which never gave us the same error message. Where could I start to troubleshoot this problem. Peter Hopfgartner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
