On Thu, Feb 16, 2017 at 11:45 AM, Justin Workman <jus...@photolynx.com> 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 >> 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 > > > Hi Tom, > > My name is Justin, and I am $customer as it were. As Peter explained, we > haven't seen the segfaults anymore since disabling parallel queries. This > works as a quick fix and is much appreciated! If you would still like to get > to the bottom of this, I am willing to help out with more information as > needed. My knowledge of PG internals is extremely limited so I don't know > how much help I can be, but we'd like to see this resolved beyond the quick > fix, or at least understand why it happened. >
Thanks Justin for the confirmation. Is it possible for you to get a standalone test case with which we can reproduce the problem? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers