It very much looks like a problem I had before
do you have back trace, I will say for sure.
-----Original Message-----
From: Luis Magaña [mailto:joe666@gnovus.com]
Sent: Wednesday, July 16, 2003 10:12 AM
To: Andrew Sullivan
Cc: Postgresql General Mail List
Subject: Re: [GENERAL] ODBC query problem
Thanks,
yes, it's running solaris 8 on a SPARC with SCSI disk.
It will be really hard for me to turn the system off in order to check
the disk for surface errors since is a system in production.
Howver, I have a core file dumped whenever this happens. Let me find out
how to do the backtrace and I'll show it to you gladly.
Thanks for the help.
On Wed, 2003-07-16 at 11:47, Andrew Sullivan wrote:
> On Wed, Jul 16, 2003 at 11:32:41AM -0500, Luis Maga?a wrote:
> > 2003-07-16 11:26:48 [1629] LOG: query: select relname, nspname,
> > relkind from pg_catalog.pg_class, pg_catalog.pg_namespace where
relkind
> > in ('r', 'v') and nspname like 'public' and relname like
> > 'diario_factura_embarque' and relname !~ '^pg_|^dd_' and
> > pg_namespace.oid = relnamespace order by nspname, relname
> > 2003-07-16 11:26:49 [1623] LOG: server process (pid 1629) was
> > terminated by signal 11
>
> You don't say what platform you're running on, but I think for more
> UNIXes sig 11 is SIGSEGV. SInce you always get it with the same
> query, I'd suspect (1) a bad library, which is causing buffer
> overflows (2) bad disk, which has put a bad block on your disk for
> one of the requested tables (which then causes the crash) or (3), and
> much less likely, bad RAM. Check your hardware, and let us know
> whether you have a core file somewhere whence you can get a backtrace
> (actually, since it's reproducible, you ought to be able to get a
> backtrace while running the query).
>
> A
--
Luis Magaña.
Invernadero Santa Rita.
www.santarita.com.mx
--
Luis Magaña.
Gnovus Networks & Software.
www.gnovus.com
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster