Re: [HACKERS] Possible issue with expanded object infrastructure on Postgres 9.6.1
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Possible issue with expanded object infrastructure on Postgres 9.6.1 |
Дата | |
Msg-id | 12835.1484879951@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | [HACKERS] Possible issue with expanded object infrastructure on Postgres 9.6.1 (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: [HACKERS] Possible issue with expanded object infrastructure onPostgres 9.6.1
Re: [HACKERS] Possible issue with expanded object infrastructure onPostgres 9.6.1 |
Список | pgsql-hackers |
Peter Geoghegan <pg@heroku.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
В списке pgsql-hackers по дате отправления: