Home > mailing lists

Thread: postgresql9.1.6 core dump

postgresql9.1.6 core dump

From

hiroyuki shiga

Date:

11 October 2013, 07:43:14

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

From

Tom Lane

Date:

11 October 2013, 11:04:22

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

From

hiroyuki shiga

Date:

11 October 2013, 13:52:09

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

From

Adrian Klaver

Date:

11 October 2013, 16:36:32

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

From

Alvaro Herrera

Date:

11 October 2013, 18:36:35

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

From

Adrian Klaver

Date:

11 October 2013, 22:50:19

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

From

Jeff Janes

Date:

12 October 2013, 01:40:16

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

From

John R Pierce

Date:

12 October 2013, 01:48:40

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