Re: ODBC query problem
От | Luis Magaña |
---|---|
Тема | Re: ODBC query problem |
Дата | |
Msg-id | 1058375538.14587.3.camel@kerberus.santarita.intranet обсуждение исходный текст |
Ответ на | Re: ODBC query problem (Andrew Sullivan <andrew@libertyrms.info>) |
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: