Postgres Pro
Downloads
Home   >   mailing lists

Thread: Vacuum Fail -- sudden death of backend process.......

Vacuum Fail -- sudden death of backend process.......

From
이바다
Date:
Hi~, I am a postgresql user in Korea, since 1999.

I have been interested in Tuple-Toaster Project, and was greatly pleased
when [text] type supported unlimit characters in version 7.1.

I was upgraded my database from 7.0.3 to 7.1.2 - we use this database for web service..
http://www.report815.com

I applied it to develop the site, but there is a problem in vacuuming.

I was upgraded my database to 7.1.3 again, and drop index / create index, and reindex the tables in single mode.
But I can't proceeding a vacuuming.  My database always prints the error messages below.

=======================================================
[postgres@local pgsql] vacuumdb -z r815
pqReadData() -- backend closed the channel unexpectedly.
        This probably means the backend terminated abnormally
        before or while processing the request.
connection to server was lost
vacuumdb: vacuum  r815 failed
=======================================================


There is no "-z" option, my database proceed a vacuuming.

=======================================================
[postgres@local pgsql] vacuumdb r815
VACUUM
=======================================================


In the db, r815, all other tables can be vacuumed, but only one table cannot.


                                   Table "freefind"
 Attribute |           Type           |                    Modifier
-----------+--------------------------+------------------------------------------------
 idxnum    | integer                  | not null default nextval('seq_freefind'::text)
 uname     | character varying(10)    | not null
 upwd      | character varying(20)    | not null
 email     | character varying(150)   | not null
 telnum    | character varying(20)    | not null
 hpnum     | character varying(20)    | not null
 title     | character varying(255)   | not null
 asktext   | text                     | not null
 askip     | character varying(15)    | not null
 askday    | timestamp with time zone | not null default now()
 ansid     | character varying(30)    |
 ansmail   | character varying(150)   |
 anstext   | text                     |
 ansip     | character varying(15)    |
 ansday    | timestamp with time zone |
 viewnum   | integer                  | not null default 0
 status    | integer                  | not null default 0
 ansrem    | text                     |
Index: freefind_pkey



Etc Informations :

=======================================================
OS : RedHat Linux, Kernel 2.4.2-2
Web Server : Apache 1.3.20
Web Script Language : PHP 4.0.6

Sometimes, field [anstext] has 20,000 ~ 50,000 characters.
=======================================================




I want to know, what is the problem?, and how can I fix it?

Thank you so much for reading poor English.





Appendix : GDB stack tracing report  :-)

========================================================================================================

#0  strcoll () at strcoll.c:229
        nrules = 1
        rulesets = (unsigned char *) 0x40295054
        table = (int32_t *) 0x40295058
        weights = (unsigned char *) 0x40295458
        extra = (unsigned char *) 0x4029a994
        indirect = (int32_t *) 0x4029ade0
        pass = 0
        result = 0
        us1 = (
    unsigned char *) 0x826dbbd "■■■학위논문■■■\t\r\n__SEP__\t등소평의 정치리더쉽 연구 - 개혁기 중국의 정발전에 미치는 영향을 중심으로/ 하범식 국민대 정치대학원 2000
324.22ㅎ133ㄷ 학위논문(석사\t) 유\r\n__SEP__\t중국의 개혁정책노선에 "... 
        us2 = (
    unsigned char *) 0x827a65c "\t사씨남정기에 관한
자료───────────────────────────\t\r\n__SEP__\t■■■학위논문■■■\t\r\n__SEP__\t조선조고소설의서사전략과 이데올로기 연구 : 이재영 서강대 대학원 2001 811.31
ㅇ8"...
        s1len = 11499
        s2len = 3221219228
        idx1arr = (int32_t *) 0x4047a008
        idx2arr = (int32_t *) 0x40491048
        rule1arr = (unsigned char *) 0x404a8088
        rule2arr = (unsigned char *) 0x404aad73
        idx1max = 0
        idx2max = 0
        idx1cnt = 0
        idx2cnt = 0
        idx1now = 0
        idx2now = 0
        backw1_stop = 0
        backw2_stop = 4294967295
        backw1 = 4294967295
        backw2 = 4294967295
        val1 = 1
        val2 = 0
        position = 0
        seq1len = 0
        seq2len = 0
        use_malloc = 1
        nrules = 1
        rulesets = (unsigned char *) 0x40295054
        table = (int32_t *) 0x40295058
        weights = (unsigned char *) 0x40295458
        extra = (unsigned char *) 0x4029a994
        indirect = (int32_t *) 0x4029ade0
        result = 0
        us1 = (
    unsigned char *) 0x826dbbd "■■■학위논문■■■\t\r\n__SEP__\t등소평의 정치리더쉽 연구 - 개혁기 중국의 정발전에 미치는 영향을 중심으로/ 하범식 국민대 정치대학원 2000
324.22ㅎ133ㄷ 학위논문(석사\t) 유\r\n__SEP__\t중국의 개혁정책노선에 "... 
        us2 = (
    unsigned char *) 0x827a65c "\t사씨남정기에 관한
자료───────────────────────────\t\r\n__SEP__\t■■■학위논문■■■\t\r\n__SEP__\t조선조고소설의서사전략과 이데올로기 연구 : 이재영 서강대 대학원 2001 811.31
ㅇ8"...
        s1len = 11499
        idx1arr = (int32_t *) 0x4047a008
        idx2arr = (int32_t *) 0x40491048
        rule1arr = (unsigned char *) 0x404a8088
        rule2arr = (unsigned char *) 0x404aad73
        idx1max = 0
        idx2max = 0
        idx1cnt = 0
        idx2cnt = 0
        idx1now = 0
        idx2now = 0
        backw1_stop = 0
        backw2_stop = 4294967295
        backw1 = 4294967295
        backw2 = 4294967295
        val1 = 1
        val2 = 0
        position = 0
        seq1len = 0
        seq2len = 0
        use_malloc = 1
#1  0x0813f616 in varstr_cmp () at eval.c:41
        ap = (void **) 0x826dbbc
        digval = 0
        digval = 0
        digval = 0
        digval = 0
        p = 0x2ceb
        result = 136764348
        result = 11499
#2  0x0813f663 in text_cmp () at eval.c:41
        ap = (void **) 0xbfffe870
        digval = 0
        digval = 0
        digval = 0
        digval = 0
        p = 0x826aeb0 "\t■■■학위논문■■■\t\r\n__SEP__\t등소평의 정치리더쉽 연구 - 개혁기 중국의 정발전에 미치는 영향을 중심으로/ 하범식 국민대 정치대학원 2000 324.22
ㅎ133ㄷ학위논문(석사\t) 유\r\n__SEP__\t중국의 개혁정책노선에"... 
        result = 3221219440
        result = 136752816
#3  0x0813f79e in text_lt () at eval.c:41
        ap = (void **) 0xbfffe870
        digval = 0
        digval = 0
        digval = 0
        digval = 0
        p = 0x8274a24 "\024\\"
        result = 3221219440
        result = 136792612
#4  0x081529c2 in FunctionCall2 () at eval.c:41
        ap = (void **) 0x813f774
        digval = 0
        digval = 0
        digval = 0
        digval = 0
        p = 0x824c114 "t?023\b?002"
        result = 135526260
        result = 136626452
#5  0x080c0739 in attr_stats () at eval.c:41
        ap = (void **) 0x813f774
        digval = 0
        digval = 0
        digval = 0
        digval = 0
        p = 0x826aeac "?"
        result = 135526260
        result = 136752812
#6  0x080c0385 in analyze_rel () at eval.c:41
        ap = (void **) 0x8257ade
        digval = 0
        digval = 0
        digval = 0
        digval = 0
        p = 0x404547a0 "t"
        result = 136674014
        result = 1078282144
#7  0x080bb542 in vac_vacuum () at eval.c:41
        ap = (void **) 0x0
        digval = 0
        digval = 0
        digval = 0
        digval = 0
        p = 0x0
        result = 0
        result = 0
#8  0x080bb4b1 in vacuum () at eval.c:41
        ap = (void **) 0x0
        digval = 0
        digval = 0
        digval = 0
        digval = 0
        p = 0x822391c "\221\001"
        result = 0
        result = 136460572
#9  0x08118223 in ProcessUtility () at eval.c:41
        ap = (void **) 0x82497bc
        digval = 0
        digval = 0
        digval = 0
        digval = 0
        p = 0x8249690 "{\002"
        result = 136615868
        result = 136615568
#10 0x08116039 in pg_exec_query_string () at eval.c:41
        ap = (void **) 0x82497bc
        digval = 0
        digval = 0
        digval = 0
        digval = 0
        p = 0x822391c "\221\001"
        result = 136615868
        result = 136460572
#11 0x0811713e in PostgresMain () at eval.c:41
        ap = (void **) 0x8223804
        digval = 0
        digval = 0
        digval = 0
        digval = 0
        p = 0x82494dc "?224$\b\020"
        result = 136460292
        result = 136615132
#12 0x080fe834 in DoBackend () at eval.c:41
        ap = (void **) 0xbfffecc0
        digval = 0
        digval = 0
        digval = 0
        digval = 0
        p = 0xbfffeb6c "\004"
        result = 3221220544
        result = 3221220204
#13 0x080fe427 in BackendStartup () at eval.c:41
        ap = (void **) 0x821ae70
        digval = 0
        digval = 0
        digval = 0
        digval = 0
        p = 0x0
        result = 136425072
        result = 0
#14 0x080fd649 in ServerLoop () at eval.c:41
        ap = (void **) 0x821ae70
        digval = 0
        digval = 0
        digval = 0
        digval = 0
        p = 0x0
        result = 136425072
        result = 0
#15 0x080fd088 in PostmasterMain () at eval.c:41
        ap = (void **) 0x15
        digval = 0
        digval = 0
        digval = 0
        digval = 0
        p = 0x1
        result = 21
        result = 1
#16 0x080dd525 in main () at eval.c:41
        ap = (void **) 0x8198c97
        digval = 0
        digval = 0
        digval = 0
        digval = 0
        p = 0xbffff7fc "VACUUM"
        result = 135892119
        result = 3221223420
#17 0x400f9177 in __libc_start_main (main=0x80dd3c4 , argc=5, ubp_av=0xbffff6ac, init=0x80659e8 <_init>,
    fini=0x815f9d0 <_fini>, rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffff69c) at
../sysdeps/generic/libc-start.c:129
        ubp_av = (char **) 0xbffff6ac
        fini = (void (*)()) 0x40016b64 <_dl_debug_mask>
        rtld_fini = (void (*)()) 0x404a8088
        ubp_ev = (char **) 0xbffff6c4
-------------------------------------------------
DreamWiz Free Mail @ http://www.dreamwiz.com/
DreamSearch Click the world!!! http://search.dreamwiz.com/

Re: Vacuum Fail -- sudden death of backend process.......

From
Tom Lane
Date:
=?EUC-KR?B?wMy52bTZ?= <postgresql@dreamwiz.com> writes:
> Appendix : GDB stack tracing report  :-)

> #0  strcoll () at strcoll.c:229

Hmm, are you using a platform that uses glibc?  If so, I think you are
getting bit by a known bug in the strcoll() library routine.  Update to
glibc 2.2.3 or later.  See bug report at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=36539

            regards, tom lane

Re: Vacuum Fail -- sudden death of backend process.......

From
Stephan Szabo
Date:
On Tue, 23 Oct 2001, [EUC-KR] �̹ٴ� wrote:

> I was upgraded my database to 7.1.3 again, and drop index / create index, and reindex the tables in single mode.
> But I can't proceeding a vacuuming.  My database always prints the error messages below.
>
> =======================================================
> [postgres@local pgsql] vacuumdb -z r815
> pqReadData() -- backend closed the channel unexpectedly.
>         This probably means the backend terminated abnormally
>         before or while processing the request.
> connection to server was lost
> vacuumdb: vacuum  r815 failed
> =======================================================

What version of glibc are you using?  There were bugs in
glibc-2.2.2 (the version that comes with redhat 7.1) that
caused crashes in strcoll I think.
If not, does a select * from freefind; work?