On Tue, Nov 27, 2018 at 10:24:52AM -0800, Andres Freund wrote:
> And pushed. Justin, thanks again for reporting the bug and then
> narrowing it down to a reproducible test case! Would've been much harder
> to diagnose without that.
>
> I'll look into your comments patch in a bit.
Thanks for imple
On 2018-11-27 00:26:55 -0800, Andres Freund wrote:
> Hi,
>
> On 2018-11-26 22:56:09 -0600, Justin Pryzby wrote:
> > On Mon, Nov 26, 2018 at 07:00:35PM -0800, Andres Freund wrote:
> > > Could you check that the attached patch this also fixes your original
> > > issue? Going through the code to see
Hi,
On 2018-11-26 22:56:09 -0600, Justin Pryzby wrote:
> On Mon, Nov 26, 2018 at 07:00:35PM -0800, Andres Freund wrote:
> > Could you check that the attached patch this also fixes your original
> > issue? Going through the code to see if there's other occurances of
> > this.
>
> Confirmed that fi
On Mon, Nov 26, 2018 at 07:00:35PM -0800, Andres Freund wrote:
> Could you check that the attached patch this also fixes your original
> issue? Going through the code to see if there's other occurances of
> this.
Confirmed that fixes my crash.
Thanks,
Justin
On 2018-11-17 17:37:15 -0600, Justin Pryzby wrote:
> On Fri, Nov 16, 2018 at 10:24:46AM -0600, Justin Pryzby wrote:
> > On Fri, Nov 16, 2018 at 08:38:26AM -0600, Justin Pryzby wrote:
> > > The table is not too special, but was probably ALTERed to add columns a
> > > good
> > > number of times by o
On Fri, Nov 16, 2018 at 10:24:46AM -0600, Justin Pryzby wrote:
> On Fri, Nov 16, 2018 at 08:38:26AM -0600, Justin Pryzby wrote:
> > The table is not too special, but was probably ALTERed to add columns a good
> > number of times by one of our processes. It has ~1100 columns, including
> > arrays,
On Fri, Nov 16, 2018 at 05:47:24PM -0800, Andres Freund wrote:
> That's probably just the same issue as before, namely random data
> somehow being produced as the result of tuple deforming.
Does this help at all?
ts=# SELECT utrancell FROM child.daily_eric_umts_rnc_utrancell_view_201807
LIMIT 9;
Hi,
On 2018-11-16 19:23:44 -0600, Justin Pryzby wrote:
> On Fri, Nov 16, 2018 at 08:29:27AM -0800, Andres Freund wrote:
> > > On Thu, Nov 15, 2018 at 04:17:51PM -0800, Andres Freund wrote:
> > > > I'm about to commit some changes to 12/master that'd possibly make it
> > commit 15d8f83128e15de97de6
On Fri, Nov 16, 2018 at 08:29:27AM -0800, Andres Freund wrote:
> > On Thu, Nov 15, 2018 at 04:17:51PM -0800, Andres Freund wrote:
> > > I'm about to commit some changes to 12/master that'd possibly make it
> commit 15d8f83128e15de97de61430d0b9569f5ebecc26
I don't think it had to do with your commi
On Fri, Nov 16, 2018 at 08:38:26AM -0600, Justin Pryzby wrote:
> BTW find attached patch which I believe corrects some comments.
Updated. Some of the changes may be gratuitous, but changed while I was
already looking.
Also note that I had to remove -flto=thin to compile under RH7.
Justin
diff -
Hi,
On 2018-11-16 08:38:26 -0600, Justin Pryzby wrote:
> On Thu, Nov 15, 2018 at 04:17:51PM -0800, Andres Freund wrote:
> > I'm about to commit some changes to 12/master that'd possibly make it
> > easier to find issues like this.
>
> Are you referring to this a future commit ?
> commit 763f2edd
On Fri, Nov 16, 2018 at 08:38:26AM -0600, Justin Pryzby wrote:
> Are you referring to this a future commit ?
this OR a future commit
> The table is not too special, but was probably ALTERed to add columns a good
> number of times by one of our processes. It has ~1100 columns, including
> arrays,
On Thu, Nov 15, 2018 at 04:17:51PM -0800, Andres Freund wrote:
> I'm about to commit some changes to 12/master that'd possibly make it
> easier to find issues like this.
Are you referring to this a future commit ?
commit 763f2edd92095b1ca2f4476da073a28505c13820
Rejigger materializing and fetching
On Thu, Nov 15, 2018 at 04:17:51PM -0800, Andres Freund wrote:
> I'm about to commit some changes to 12/master that'd possibly make it
> easier to find issues like this. Is there any chance that it's easier to
> repro this on master than making a reproducible test case?
Yes, very possibly - this i
Hi,
On 2018-11-15 18:11:05 -0600, Justin Pryzby wrote:
> On Thu, Nov 15, 2018 at 06:03:34PM -0600, Justin Pryzby wrote:
> > Verbose plan, munged for brevity/sanity due to joining wide tables, and
> > redacted since the view probably has to be considered proprietary.
> > Hopefully
> > the remaini
On Thu, Nov 15, 2018 at 06:03:34PM -0600, Justin Pryzby wrote:
> Verbose plan, munged for brevity/sanity due to joining wide tables, and
> redacted since the view probably has to be considered proprietary. Hopefully
> the remaining bits are still useful. I replaced column names with x.
Actually
On Thu, Nov 15, 2018 at 03:14:01PM -0800, Andres Freund wrote:
> Huh, that's the same crash? Because I don't see any evalexpr functions
> in the stack, and without those the above bt should have worked...
TTBOMK it's the same ..
Is it odd if i'm seeing this: (odd because of "ANOTHER") ?
I guess t
Hi,
On 2018-11-15 17:03:35 -0600, Justin Pryzby wrote:
> On Thu, Nov 15, 2018 at 02:47:55PM -0800, Andres Freund wrote:
> > > (gdb) bt
> > > #0 0x7f08127e814e in ?? ()
> > > #1 0x in ?? ()
> >
> > Could you enable jit_debugging_support and reproduce? That should give
> > a
On Thu, Nov 15, 2018 at 02:47:55PM -0800, Andres Freund wrote:
> > (gdb) bt
> > #0 0x7f08127e814e in ?? ()
> > #1 0x in ?? ()
>
> Could you enable jit_debugging_support and reproduce? That should give
> a more useful backtrace.
Core was generated by `postgres: pryzbyj ts [l
Hi,
On 2018-11-15 16:39:59 -0600, Justin Pryzby wrote:
> Crash is reproducible but only when JIT=on.
>
> postgresql11-llvmjit-11.1-1PGDG.rhel7.x86_64
>
> [2769871.453033] postmaster[8582]: segfault at 7f083bddb780 ip
> 7f08127e814e sp 7ffe463506e0 error 4
> [2770774.470600] postmaster[2
20 matches
Mail list logo
