From: | Justin Workman <justin(at)photolynx(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Possible issue with expanded object infrastructure on Postgres 9.6.1 |
Date: | 2017-02-16 06:15:49 |
Message-ID: | CAOxz3fqK9Y0GntL8MDoeZjy2Ot_6Lx1YvHAY6Bd1vYkUp-iS_A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> 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.
album_photo_assignments.id, album_photo_assignments.album_id,
album_photo_assignments.photo_id and albums.id are all UUID columns.
albums.deleted_at is a timestamp.
Thanks so much for your time,
Justin Workman
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Khandekar | 2017-02-16 06:34:04 | Re: Parallel Append implementation |
Previous Message | Peter Geoghegan | 2017-02-16 06:13:57 | Re: ICU integration |