[Postgres-xl-general] autovacuum on coord cause core dump

Jov amutu at amutu.com
Tue Oct 14 23:58:54 PDT 2014


It is not reliable reproducible.On our cluster,we can get the avage 1 core
every coord per day,and the core dump happens at different time(we have 4
coord nodes and 16 data nodes).

we set the assert when build the src,so is just core dump,no else message.

we will try the path and feed back.

Jov
blog: http:amutu.com/blog <http://amutu.com/blog>

2014-10-15 13:43 GMT+08:00 Pavan Deolasee <pavan.deolasee at gmail.com>:

>
>
> On Tue, Oct 14, 2014 at 9:01 AM, Jov <amutu at amutu.com> wrote:
>
>> Program terminated with signal 6, Aborted.
>> #
>> (gdb) f 3
>> #3  0x00000000005f2a0b in handle_response (conn=0x253ddf8,
>> combiner=0x7fff51270720) at execRemote.c:2219
>> 2219                    Assert(conn->combiner == combiner ||
>> conn->combiner == NULL);
>> (gdb) p conn->combiner
>> $1 = (struct ResponseCombiner *) 0x269d120
>>
>
>
> Thanks Jov for the report. Is there something special about the table
> that's being autovacuumed or auto analysed? I'm curious why an autovac on a
> coordinator would need to open datanode connections. Are there indexes
> using functions which may in turn access datanodes?
>
> Are there any error messages in the coordinator or datanode logs?
>
> BTW, if the crash is reproducible, it might be worth trying with the
> attached patch and see if it helps.
>
> Thanks,
> Pavan
>
> --
> Pavan Deolasee
> http://www.linkedin.com/in/pavandeolasee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.postgres-xl.org/pipermail/postgres-xl-general-postgres-xl.org/attachments/20141015/8f5a8b36/attachment.htm>


More information about the postgres-xl-general mailing list