On Tue, Aug 8, 2017 at 8:17 PM, Tom Lane wrote:
> Peter Geoghegan writes:
> > On Thu, Jan 19, 2017 at 5:45 PM, Peter Geoghegan wrote:
> >> A customer is on 9.6.1, and complains of a segfault observed at least
> >> 3 times.
> > ...
> > For the
Peter Geoghegan writes:
> On Thu, Jan 19, 2017 at 5:45 PM, Peter Geoghegan wrote:
>> A customer is on 9.6.1, and complains of a segfault observed at least
>> 3 times.
> ...
> For the sake of the archives: this now looks very much like the issue
> that Tom just
On Thu, Jan 19, 2017 at 5:45 PM, Peter Geoghegan wrote:
> A customer is on 9.6.1, and complains of a segfault observed at least
> 3 times.
> 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
On Thu, Feb 16, 2017 at 11:45 AM, Justin Workman wrote:
>> 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
>
> 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
On Thu, Jan 19, 2017 at 6:39 PM, Tom Lane wrote:
> 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.
I no longer work at
On Thu, Jan 19, 2017 at 9:39 PM, Tom Lane wrote:
> 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
Peter Geoghegan 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
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:
Jan 11 16:11:07 ip-10-0-118-82 kernel: [41913.530453] traps:
postgres[6561] general protection ip:55fcf08b0491 sp:7ffc17dfa650
error:0 in postgres[55fcf0557000+638000]
Jan 11