Обсуждение: postgresql9.1.6 core dump

Поиск
Список
Период
Сортировка

postgresql9.1.6 core dump

От
hiroyuki shiga
Дата:
Hello.

I'm having problems postgesql coredump.
Do you have any idea?.

OS:Scientific Linux release 6.1
DB:postgresql91-9.1.6
MEM:4G


(gdb) bt full
#0  SearchCatCacheList (cache=0x1d70440, nkeys=1, v1=<value optimized out>,
    v2=<value optimized out>, v3=<value optimized out>, v4=<value optimized out>)
    at catcache.c:1450
        hashValue = 1943050110
        hashIndex = 1918
        relation = 0x7f6983ede610
        scandesc = 0x1db11e0
        save_exception_stack = 0x7fffc61a1bd0
        save_context_stack = 0x0
        local_sigjmp_buf = {{__jmpbuf = {140736516985344, -1013623458724204964,
              31134224, 140736516986976, 0, 1, 1013713306157690460,
              -1013624314715328932}, __mask_was_saved = 0, __saved_mask = {__val = {
                31148304, 0, 6365529, 2262149739, 31148304, 31148304, 140091178270512,
                44, 6370319, 140736516985856, 6437365, 0, 4963415, 1, 13593016,
                8070450532247928832}}}}
        cur_skey = {{sk_flags = 0, sk_attno = 1, sk_strategy = 3, sk_subtype = 0,
            sk_collation = 0, sk_func = {fn_addr = 0x67c230 <nameeq>, fn_oid = 62,
              fn_nargs = 2, fn_strict = 1 '\001', fn_retset = 0 '\000',
              fn_stats = 2 '\002', fn_extra = 0x0, fn_mcxt = 0x1d2d840, fn_expr = 0x0},
            sk_argument = 30378016}, {sk_flags = 0, sk_attno = 17, sk_strategy = 3,
            sk_subtype = 0, sk_collation = 0, sk_func = {
              fn_addr = 0x684800 <oidvectoreq>, fn_oid = 679, fn_nargs = 2,
              fn_strict = 1 '\001', fn_retset = 0 '\000', fn_stats = 2 '\002',
              fn_extra = 0x0, fn_mcxt = 0x1d2d840, fn_expr = 0x0}, sk_argument = 0}, {
            sk_flags = 0, sk_attno = 2, sk_strategy = 3, sk_subtype = 0,
            sk_collation = 0, sk_func = {fn_addr = 0x6846e0 <oideq>, fn_oid = 184,
              fn_nargs = 2, fn_strict = 1 '\001', fn_retset = 0 '\000',
              fn_stats = 2 '\002', fn_extra = 0x0, fn_mcxt = 0x1d2d840, fn_expr = 0x0},
            sk_argument = 0}, {sk_flags = 0, sk_attno = 0, sk_strategy = 0,
            sk_subtype = 0, sk_collation = 0, sk_func = {fn_addr = 0, fn_oid = 0,
              fn_nargs = 0, fn_strict = 0 '\000', fn_retset = 0 '\000',
              fn_stats = 0 '\000', fn_extra = 0x0, fn_mcxt = 0x0, fn_expr = 0x0},
            sk_argument = 0}}
        lHashValue = 2904526133
        elt = 0xff
        cl = <value optimized out>
        ct = <value optimized out>
        ctlist = 0x0
        ctlist_item = <value optimized out>
        nmembers = <value optimized out>
        ordered = 1 '\001'
        ntp = 0x1cf91d0
        oldcxt = <value optimized out>
        i = <value optimized out>
#1  0x00000000004beb64 in FuncnameGetCandidates (names=<value optimized out>, nargs=1,
    argnames=0x0, expand_variadic=1 '\001', expand_defaults=1 '\001') at namespace.c:714
        resultList = 0x0
        any_special = 0 '\000'
        schemaname = 0x0
        funcname = 0x1cf8820 "count"
        namespaceId = 0
        catlist = <value optimized out>
        i = <value optimized out>
#2  0x00000000004f9e10 in func_get_detail (funcname=0x1cf87b0, fargs=0x1db1140,
    fargnames=0x0, nargs=1, argtypes=0x7fffc61a16c0, expand_variadic=1 '\001',
    expand_defaults=1 '\001', funcid=0x7fffc61a1874, rettype=0x7fffc61a1878,
    retset=0x7fffc61a187f "", nvargs=0x7fffc61a1870, true_typeids=0x7fffc61a1868,
    argdefaults=0x7fffc61a1860) at parse_func.c:950
        raw_candidates = <value optimized out>
        best_candidate = <value optimized out>
        __func__ = "func_get_detail"
#3  0x00000000004fa612 in ParseFuncOrColumn (pstate=0x1cf8e10, funcname=0x1cf87b0,
    fargs=0x1db1140, agg_order=0x0, agg_star=0 '\000', agg_distinct=0 '\000',
    func_variadic=0 '\000', over=0x0, is_column=0 '\000', location=13)
    at parse_func.c:212
        rettype = <value optimized out>
        funcid = <value optimized out>
        l = <value optimized out>
        nextl = <value optimized out>
        first_arg = 0x1db1210
        nargs = <value optimized out>
        nargsplusdefs = <value optimized out>
        actual_arg_types = {23, 0, 0, 0, 0, 0, 7392693, 0, 0, 0, 1, 0, 2, 0, 5941475, 0,
          0, 0, 19, 0, 2, 0, 30380112, 0, 1, 0, 30379536, 0, 19, 0, 30380112, 0,
          30379536, 0, 5245868, 0, 0, 0, 31131992, 0, 31131992, 0, 2, 0, 30380112, 0,
          5246540, 0, 7, 0, 7393125, 0, 31134224, 0, 31134224, 0, 0, 0, 31133888, 0, 0,
          0, 30379536, 0, 19, 0, 0, 0, 30378280, 0, 5246937, 0, 31132080, 0, 3, 0,
          30379536, 0, 5246540, 0, 0, 0, 30378120, 0, 0, 0, 30379536, 0, 30378088, 0,
          30378280, 0, 30377096, 0, 5206771, 0, 7, 0, 31134304, 0}
        declared_arg_types = <value optimized out>
        argnames = <value optimized out>
        argdefaults = <value optimized out>
        retval = 0x1cf91d4
        retset = <value optimized out>
        nvargs = <value optimized out>
        fdresult = <value optimized out>
        __func__ = "ParseFuncOrColumn"
#4  0x00000000004f6a3f in transformFuncCall (pstate=0x1cf8e10, expr=0x1cf8760)
    at parse_expr.c:1242
        targs = <value optimized out>
        args = <value optimized out>
#5  transformExpr (pstate=0x1cf8e10, expr=0x1cf8760) at parse_expr.c:238
        result = 0x0
        __func__ = "transformExpr"
#6  0x0000000000502806 in transformTargetEntry (pstate=0x1cf8e10, node=0x1cf8760,
    expr=0x0, colname=<value optimized out>, resjunk=<value optimized out>)
    at parse_target.c:91
No locals.
#7  0x00000000005034b5 in transformTargetList (pstate=0x1cf8e10,
    targetlist=<value optimized out>) at parse_target.c:162
        res = <value optimized out>
        p_target = <value optimized out>
        o_target = 0x1cf86f0
#8  0x00000000004d702c in transformSelectStmt (pstate=0x1cf8e10, parseTree=0x1cf8488)
    at analyze.c:900
        qry = 0x1cf8f40
        qual = <value optimized out>
        l = <value optimized out>
#9  transformStmt (pstate=0x1cf8e10, parseTree=0x1cf8488) at analyze.c:187
        n = 0x1cf8488
        result = <value optimized out>
#10 0x00000000004d8250 in parse_analyze_varparams (parseTree=0x1cf8488,
    sourceText=0x1da80a1 "SELECT PATH, COUNT(SITE_ID) FROM ACCESS_LOG_05 WHERE SITE_ID = $1 GROUP BY PATH ORDER BY PATH", paramTypes=0x7fffc61a1aa8, numParams=0x7fffc61a1aa4)
    at analyze.c:122
        pstate = 0x1cf8e10
        query = <value optimized out>
#11 0x00000000006339fd in exec_parse_message (
    query_string=0x1da80a1 "SELECT PATH, COUNT(SITE_ID) FROM ACCESS_LOG_05 WHERE SITE_ID = $1 GROUP BY PATH ORDER BY PATH", stmt_name=0x1da80a0 "", paramTypes=0x1da88c0,
    numParams=1) at postgres.c:1254
        query = <value optimized out>
        snapshot_set = 1 '\001'
        i = <value optimized out>
        oldcontext = 0x1d2e500
        parsetree_list = <value optimized out>
        raw_parse_tree = 0x1cf81d0
        commandTag = 0x826012 "SELECT"
        querytree_list = <value optimized out>
        stmt_list = <value optimized out>
        is_named = 0 '\000'
        fully_planned = <value optimized out>
        save_log_statement_stats = 0 '\000'
        msec_str = "]\000\000\000\000\000\000\000\241\200\332\001", '\000' <repeats 12 times>, "T\204Y\000\000\000\000"
        __func__ = "exec_parse_message"
#12 0x000000000063456c in PostgresMain (argc=<value optimized out>,
    argv=<value optimized out>, username=<value optimized out>) at postgres.c:3997
        stmt_name = <value optimized out>
        query_string = 0x1da80a1 "SELECT PATH, COUNT(SITE_ID) FROM ACCESS_LOG_05 WHERE SITE_ID = $1 GROUP BY PATH ORDER BY PATH"
        numParams = 1
        paramTypes = 0x1da88c0
        dbname = <value optimized out>
        firstchar = <value optimized out>
        input_message = {data = 0x1da80a0 "", len = 101, maxlen = 1024, cursor = 101}
        local_sigjmp_buf = {{__jmpbuf = {140736516988064, -1013625157805298084, 2, 2,
              -9187201950435737471, 0, 1013713306348531292, -1013624294113694116},
            __mask_was_saved = 1, __saved_mask = {__val = {0, 0, 65280, 0, 0,
                18446744073709486080, 18446744073709551615, 18446744073709551615,
                18374967954648334335, 0, 0, 0, 0, 0, 0, 0}}}}
        send_ready_for_query = 0 '\000'
        __func__ = "PostgresMain"
#13 0x00000000005f54c9 in BackendRun () at postmaster.c:3617
        ac = 2
        secs = 434261935
        usecs = 398782
        i = <value optimized out>
        av = 0x1cd9428
        maxac = <value optimized out>
#14 BackendStartup () at postmaster.c:3302
        bn = 0x1cfd2e0
        pid = 0
#15 ServerLoop () at postmaster.c:1466
        rmask = {fds_bits = {8, 0 <repeats 15 times>}}
        selres = <value optimized out>
        readmask = {fds_bits = {56, 0 <repeats 15 times>}}
        nSockets = 6
        now = <value optimized out>
        last_touch_time = 1380944820
        __func__ = "ServerLoop"
#16 0x00000000005f7c71 in PostmasterMain (argc=<value optimized out>,
    argv=<value optimized out>) at postmaster.c:1127
        opt = <value optimized out>
        status = <value optimized out>
        userDoption = <value optimized out>
        listen_addr_saved = 1 '\001'
        i = <value optimized out>
        __func__ = "PostmasterMain"
#17 0x0000000000599520 in main (argc=7, argv=0x1cd6100) at main.c:199
No locals.


Re: postgresql9.1.6 core dump

От
Tom Lane
Дата:
hiroyuki shiga <hshiga@gmail.com> writes:
> I'm having problems postgesql coredump.
> Do you have any idea?.

Can you provide a self-contained test case that causes that?

            regards, tom lane


Re: postgresql9.1.6 core dump

От
hiroyuki shiga
Дата:
Thank you for reply.

but .... I can't provide a self-contained test case.


2013/10/11 Tom Lane <tgl@sss.pgh.pa.us>
hiroyuki shiga <hshiga@gmail.com> writes:
> I'm having problems postgesql coredump.
> Do you have any idea?.

Can you provide a self-contained test case that causes that?

                        regards, tom lane

Re: postgresql9.1.6 core dump

От
Adrian Klaver
Дата:
On 10/11/2013 03:51 AM, hiroyuki shiga wrote:
> Thank you for reply.
>
> but .... I can't provide a self-contained test case.
>

So what are you doing when you get the core dump?


--
Adrian Klaver
adrian.klaver@gmail.com


Re: postgresql9.1.6 core dump

От
Alvaro Herrera
Дата:
Adrian Klaver escribió:
> On 10/11/2013 03:51 AM, hiroyuki shiga wrote:
> >Thank you for reply.
> >
> >but .... I can't provide a self-contained test case.
> >
>
> So what are you doing when you get the core dump?

The query is in the backtrace:

SELECT PATH, COUNT(SITE_ID)
FROM ACCESS_LOG_05
WHERE SITE_ID = $1
GROUP BY PATH
ORDER BY PATH

And it also suggests that the crash is happening during cache lookup of
the "count" function.

Since this seems to work for pretty much everybody, I would wonder about
corrupt catalogs and/or corrupt cache; if neither, perhaps some race
condition on cache invalidation/reload.  Speculating much without any
further evidence or test case appears pointless.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


Re: postgresql9.1.6 core dump

От
Adrian Klaver
Дата:
On 10/11/2013 08:36 AM, Alvaro Herrera wrote:
> Adrian Klaver escribió:
>> On 10/11/2013 03:51 AM, hiroyuki shiga wrote:
>>> Thank you for reply.
>>>
>>> but .... I can't provide a self-contained test case.
>>>
>>
>> So what are you doing when you get the core dump?
>
> The query is in the backtrace:
>
> SELECT PATH, COUNT(SITE_ID)
> FROM ACCESS_LOG_05
> WHERE SITE_ID = $1
> GROUP BY PATH
> ORDER BY PATH
>
> And it also suggests that the crash is happening during cache lookup of
> the "count" function.

> Since this seems to work for pretty much everybody, I would wonder about
> corrupt catalogs and/or corrupt cache; if neither, perhaps some race
> condition on cache invalidation/reload.  Speculating much without any
> further evidence or test case appears pointless.

Which is where I was going with my question. The query would seem to be
the trigger for the core dump, but it does not enlighten as to the lead
up conditions. Basically with out more context answering the question
would involve a lucky guess.

>


--
Adrian Klaver
adrian.klaver@gmail.com


Re: postgresql9.1.6 core dump

От
Jeff Janes
Дата:
On Fri, Oct 11, 2013 at 3:51 AM, hiroyuki shiga <hshiga@gmail.com> wrote:
Thank you for reply.

but .... I can't provide a self-contained test case.

It that because it is too proprietary/sensitive to provide, or because the problem is not readily reproducible?
 
Cheers,

Jeff

Re: postgresql9.1.6 core dump

От
John R Pierce
Дата:
On 10/11/2013 3:51 AM, hiroyuki shiga wrote:
> but .... I can't provide a self-contained test case.

what were you doing when this coredump occured?
did any errors get logged by the postgresql server?   kernel?
what platform (operating system, version, bitsize, etc) are you running on?

a stack trace without any context is pretty meaningless.



--
john r pierce                                      37N 122W
somewhere on the middle of the left coast