Lists: | pgsql-hackers |
---|
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | phd2(at)earthling(dot)net |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] VACUUM ANALYZE problem on linux |
Date: | 1999-02-12 02:06:12 |
Message-ID: | 23300.918785172@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Oleg Broytmann <phd(at)sun(dot)med(dot)ru> writes:
>> I can test on libc5 if you still see trouble after you have verified
>> Jan's fixes for your memory exhaution problem.
> I've downloaded latest snapshot (9 Feb) and reproduced the problem with
> VACUUM ANALYZE on Debian 2.0 (glibc2).
I am not able to reproduce the problem on HPUX, using either current
sources or 6.4.2. Looks like it must be platform specific.
Could you build the backend with -g and send a gdb backtrace from the
corefile produced when the crash occurs?
regards, tom lane
From: | Oleg Broytmann <phd(at)sun(dot)med(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] VACUUM ANALYZE problem on linux |
Date: | 1999-02-12 10:23:15 |
Message-ID: | Pine.SOL2.3.96.SK.990212132035.7926D-100000@sun.med.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On Thu, 11 Feb 1999, Tom Lane wrote:
> I am not able to reproduce the problem on HPUX, using either current
> sources or 6.4.2. Looks like it must be platform specific.
Of course it is platform-specific. I reported the problem on
glibc2-based linucies, but the same database works fine (and allows VACUUM
ANALYZE) on sparc-solaris.
Don't know about libc5 linux - I have no one in hand.
> Could you build the backend with -g and send a gdb backtrace from the
> corefile produced when the crash occurs?
I'll do it this Saturday.
Oleg.
----
Oleg Broytmann National Research Surgery Centre http://sun.med.ru/~phd/
Programmers don't die, they just GOSUB without RETURN.
From: | Oleg Broytmann <phd(at)sun(dot)med(dot)ru> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] VACUUM ANALYZE problem on linux |
Date: | 1999-02-13 11:50:32 |
Message-ID: | Pine.SOL2.3.96.SK.990213144727.2119J-100000@sun.med.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Hi!
On Thu, 11 Feb 1999, Tom Lane wrote:
> Could you build the backend with -g and send a gdb backtrace from the
> corefile produced when the crash occurs?
Problem compiling with -g:
make[3]: Entering directory
`/usr/local/src/PostgreSQL/postgresql-6.4.2/src/interfaces/ecpg/preproc'
gcc -I../../../include -I../../../backend -g -Wall -Wmissing-prototypes
-I../include -DMAJOR_VERSION=2 -DMINOR_VERSION=4 -DPATCHLEVEL=4
-DINCLUDE_PATH=\"/usr/local/stow/pgsql-debug/include\"
-c y.tab.c -o y.tab.o
preproc.y:2389: parse error at end of input
preproc.y:20: warning: `struct_level' defined but not used
preproc.y:22: warning: `QueryIsRule' defined but not used
preproc.y:23: warning: `actual_type' defined but not used
preproc.y:24: warning: `actual_storage' defined but not used
preproc.y:219: warning: `remove_variables' defined but not used
preproc.y:254: warning: `reset_variables' defined but not used
preproc.y:263: warning: `add_variable' defined but not used
preproc.y:332: warning: `make1_str' defined but not used
preproc.y:341: warning: `make2_str' defined but not used
preproc.y:353: warning: `cat2_str' defined but not used
preproc.y:366: warning: `make3_str' defined but not used
preproc.y:380: warning: `cat3_str' defined but not used
preproc.y:396: warning: `make4_str' defined but not used
preproc.y:412: warning: `cat4_str' defined but not used
preproc.y:431: warning: `make5_str' defined but not used
preproc.y:449: warning: `cat5_str' defined but not used
preproc.y:471: warning: `make_name' defined but not used
preproc.y:481: warning: `output_statement' defined but not used
make[3]: *** [y.tab.o] Error 1
make[3]: Leaving directory
`/usr/local/src/PostgreSQL/postgresql-6.4.2/src/interfaces/ecpg/preproc'
Oleg.
----
Oleg Broytmann National Research Surgery Centre http://sun.med.ru/~phd/
Programmers don't die, they just GOSUB without RETURN.
From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | phd2(at)earthling(dot)net |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] VACUUM ANALYZE problem on linux |
Date: | 1999-02-13 14:41:24 |
Message-ID: | 36C58F14.94567528@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
> > Could you build the backend with -g and send a gdb backtrace from
> > the corefile produced when the crash occurs?
> Problem compiling with -g:
I'd be suprised if "-g" would do that to you. Are you sure the input
file is well-formed?
- Tom
From: | Oleg Broytmann <phd(at)sun(dot)med(dot)ru> |
---|---|
To: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] VACUUM ANALYZE problem on linux |
Date: | 1999-02-13 14:50:13 |
Message-ID: | Pine.SOL2.3.96.SK.990213174752.2576E-100000@sun.med.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Hi!
On Sat, 13 Feb 1999, Thomas G. Lockhart wrote:
> > > Could you build the backend with -g and send a gdb backtrace from
> > > the corefile produced when the crash occurs?
> > Problem compiling with -g:
>
> I'd be suprised if "-g" would do that to you. Are you sure the input
> file is well-formed?
May be not enough memory or disk space. In the beginnig of next week
I'll have new linux box, so I'll retry.
Oleg.
----
Oleg Broytmann National Research Surgery Centre http://sun.med.ru/~phd/
Programmers don't die, they just GOSUB without RETURN.
From: | Oleg Broytmann <phd(at)sun(dot)med(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] VACUUM ANALYZE problem on linux |
Date: | 1999-02-24 09:44:48 |
Message-ID: | Pine.SOL2.3.96.SK.990224124321.10537B-100000@sun.med.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Hello!
Sorry for making this late :(
On Thu, 11 Feb 1999, Tom Lane wrote:
> Could you build the backend with -g and send a gdb backtrace from the
> corefile produced when the crash occurs?
I have compiled with -g, but postgres didn't produce core. Do I need
something special on startup to generate core on crash?
Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2(at)earthling(dot)net
Programmers don't die, they just GOSUB without RETURN.
From: | Oleg Broytmann <phd(at)sun(dot)med(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] VACUUM ANALYZE problem on linux |
Date: | 1999-03-15 12:23:19 |
Message-ID: | Pine.SOL2.3.96.SK.990315151816.23120A-100000@sun.med.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Hello!
On Thu, 11 Feb 1999, Tom Lane wrote:
> Could you build the backend with -g and send a gdb backtrace from the
> corefile produced when the crash occurs?
I have a problem getting core - postgres didn't produces core. Recently
I got a suggestion (from Vadim) to attach gdb to a running process and
debug it this way. Ok, done.
To remind of the problem - I have a problem running VACUUM ANALYZE on a
glibc2 linux (Debian 2.0). On solaris it is Ok (and I got a report it is Ok
on HP-UX).
Here is the traceback. The problem is in strcoll, don't understand why.
Program received signal SIGSEGV, Segmentation fault.
0x40119587 in strcoll ()
(gdb) where
#0 0x40119587 in strcoll ()
#1 0x816cadd in varstr_cmp (arg1=0x4020fccc " ", len1=0,
arg2=0x8268604 " ", len2=0) at varlena.c:511
#2 0x816b31d in bpcharlt (arg1=0x4020fcc8 "\n", arg2=0x8268600 "\n")
at varchar.c:504
#3 0x80a1bb7 in vc_attrstats (onerel=0x8264378, vacrelstats=0x8262a10,
tuple=0x4020fc90) at vacuum.c:1630
#4 0x809ffec in vc_scanheap (vacrelstats=0x8262a10, onerel=0x8264378,
vacuum_pages=0xbfffcf84, fraged_pages=0xbfffcf78) at vacuum.c:806
#5 0x809f773 in vc_vacone (relid=32600, analyze=1 '\001', va_cols=0x0)
at vacuum.c:504
#6 0x809ed84 in vc_vacuum (VacRelP=0x0, analyze=1 '\001', va_cols=0x0)
at vacuum.c:257
#7 0x809ec3e in vacuum (vacrel=0x0, verbose=0 '\000', analyze=1 '\001',
va_spec=0x0) at vacuum.c:160
#8 0x8138c43 in ProcessUtility (parsetree=0x82464e0, dest=Remote)
at utility.c:644
#9 0x8135388 in pg_exec_query_dest (query_string=0xbfffd0d4 "vacuum
analyze;",
dest=Remote, aclOverride=0 '\000') at postgres.c:758
#10 0x8135264 in pg_exec_query (query_string=0xbfffd0d4 "vacuum analyze;")
at postgres.c:699
#11 0x813677e in PostgresMain (argc=6, argv=0xbffff15c, real_argc=8,
real_argv=0xbffffafc) at postgres.c:1645
#12 0x8111561 in DoBackend (port=0x82110f0) at postmaster.c:1541
#13 0x8110f35 in BackendStartup (port=0x82110f0) at postmaster.c:1312
#14 0x811012f in ServerLoop () at postmaster.c:757
#15 0x810fb5e in PostmasterMain (argc=8, argv=0xbffffafc) at
postmaster.c:563
#16 0x80c8c32 in main (argc=8, argv=0xbffffafc) at main.c:93
>
> regards, tom lane
>
Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2(at)earthling(dot)net
Programmers don't die, they just GOSUB without RETURN.