From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andreas Seltenreich <seltenreich(at)gmx(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [sqlsmith] Parallel worker crash on seqscan |
Date: | 2016-11-21 16:26:18 |
Message-ID: | 21029.1479745578@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Then again, that might just be a coincidence. The other thing that's
> weird here is that the Datum being passed is apparently a NULL
> pointer, which neither MakeExpandedObjectReadOnly() nor
> MakeExpandedObjectReadOnlyInternal() are prepared to deal with. I
> don't know whether it's wrong for a NULL pointer to occur here in the
> first place or whether it's wrong for those functions not to be able
> to deal with it if it does.
The former. MakeExpandedObjectReadOnly does contain a null check,
so something has passed it a zero Datum along with a claim that the
Datum is not null.
Like Ashutosh, I can't reproduce the crash, so it's hard to speculate much
further. I am wondering if 13671b4b2 somehow fixed it, though I don't see
how.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Verite | 2016-11-21 16:37:36 | Re: Improvements in psql hooks for variables |
Previous Message | Tobias Bussmann | 2016-11-21 16:24:55 | Re: Parallel execution and prepared statements |