From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Possible issue with expanded object infrastructure on Postgres 9.6.1 |
Date: | 2017-01-20 02:39:11 |
Message-ID: | 12835.1484879951@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)heroku(dot)com> writes:
> A customer is on 9.6.1, and complains of a segfault observed at least
> 3 times. In all cases, the logs look like this:
> ...
> I can use GDB to get details of the instruction pointer that appeared
> in the kernel trap error, which shows a function from the expanded
> value representation infrastructure:
It would help to know the data types of the columns involved in this
query; but just eyeballing it, it doesn't look like it involves any
array operations, so it's pretty hard to believe that the expanded-object
code could have gotten invoked intentionally. (The mere presence of
an array column somewhere in the vicinity would not do that; you'd
need to invoke an array-ish operation, or at least pass the array into
a plpgsql function.)
If I had to bet on the basis of this much info, I would bet that the
parallel-query infrastructure is dropping the ball somewhere and
transmitting a corrupted datum that accidentally looks like it is
an expanded-object reference.
If $customer wants a quick fix, I'd suggest seeing whether disabling
parallel query makes the problem go away. That might be a good first
step anyway, just to narrow down where the problem lies.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2017-01-20 02:58:25 | Re: Declarative partitioning - another take |
Previous Message | Haribabu Kommi | 2017-01-20 02:20:18 | Re: [WIP]Vertical Clustered Index (columnar store extension) |