Alvaro Herrera writes:
> Robert Haas wrote:
>> On Thu, May 5, 2016 at 4:11 PM, Andreas Seltenreich
>> wrote:
>> > I don't see these crashes anymore in c1543a8. By the amount of fuzzing
>> > done it should have happened a dozen times, so it's highly likely
>> > something in 23b09e15..c1543a8 fix
Robert Haas wrote:
> On Thu, May 5, 2016 at 4:11 PM, Andreas Seltenreich
> wrote:
> >> Amit Kapila writes:
> >>> Sounds good. So can we assume that you will try to get us the new report
> >>> with more information?
> >
> > I don't see these crashes anymore in c1543a8. By the amount of fuzzing
>
On Thu, May 5, 2016 at 4:11 PM, Andreas Seltenreich wrote:
>> Amit Kapila writes:
>>> Sounds good. So can we assume that you will try to get us the new report
>>> with more information?
>
> I don't see these crashes anymore in c1543a8. By the amount of fuzzing
> done it should have happened a do
> Amit Kapila writes:
>> Sounds good. So can we assume that you will try to get us the new report
>> with more information?
I don't see these crashes anymore in c1543a8. By the amount of fuzzing
done it should have happened a dozen times, so it's highly likely
something in 23b09e15..c1543a8 fixe
On Fri, Apr 29, 2016 at 9:45 AM, Tom Lane wrote:
>> It will
>> be helpful if you can find the offending query or plan corresponding to it?
>
> I presume the lack of debug_query_string data is because nothing is
> bothering to set debug_query_string in a worker process. Should that be
> remedied?
Amit Kapila writes:
> On Fri, Apr 29, 2016 at 7:15 PM, Tom Lane wrote:
>> but it might be worth copying over the full query from the parent
>> side.
>
> That would amount to couple of extra cycles considering we need to do it
> for each worker, but OTOH it might be a useful debugging information
Amit Kapila writes:
> On Sat, Apr 30, 2016 at 5:58 AM, Andreas Seltenreich
> wrote:
>> This sounds like it should work to capture more context when the
>> Assertion fails the next time.
>
> Sounds good. So can we assume that you will try to get us the new report
> with more information?
Ja. I
On Sat, Apr 30, 2016 at 5:58 AM, Andreas Seltenreich
wrote:
>
> Alvaro Herrera writes:
> > Amit Kapila wrote:
> >> It will be helpful if you can find the offending query or plan
> >> corresponding to it?
> >
> > So I suppose the PID of the process starting the workers should be in
> > the stack so
On Fri, Apr 29, 2016 at 7:15 PM, Tom Lane wrote:
>
> Amit Kapila writes:
> > On Fri, Apr 29, 2016 at 12:01 PM, Andreas Seltenreich <
seltenre...@gmx.de>
> > wrote:
> >> tonight's sqlsmith run yielded another core dump:
> >>
> >> TRAP: FailedAssertion("!(MyProc->lockGroupLeader == ((void *)0))",
F
On 2016-04-30 02:28:22 +0200, Andreas Seltenreich wrote:
> This sounds like it should work to capture more context when the
> Assertion fails the next time. I have to purge the catalogs a bit
> though to avoid stopping early on boring core dumps. Most of them are
> currently caused by acl.c using
On 2016-04-30 02:34:35 +0200, Andreas Seltenreich wrote:
> I didn't think the effort of creating this kind of clean-room testing
> was worth it. If reports of failed assertions with backtrace without a
> recipe to reproduce them are a nuisance, I'll avoid them in the future.
It's obviously better
Simon Riggs writes:
> It's good that the input is fuzzed, but there needs to be a way to re-run
> identical fuzzing or a way to backtrack to find what broke. Not much point
> finding bugs we can't identify later.
sqlsmith is deterministic and allows re-generating a sequence of random
queries with
Alvaro Herrera writes:
> Amit Kapila wrote:
>> It will be helpful if you can find the offending query or plan
>> corresponding to it?
>
> So I suppose the PID of the process starting the workers should be in
> the stack somewhere.
Ja, it's right on the top, but long gone by now…
> With that one s
Amit Kapila writes:
> On Fri, Apr 29, 2016 at 12:01 PM, Andreas Seltenreich
> wrote:
>> tonight's sqlsmith run yielded another core dump:
>>
>> TRAP: FailedAssertion("!(MyProc->lockGroupLeader == ((void *)0))", File:
>> "proc.c", Line: 1787)
>>
>> I couldn't identifiy a query for it though: deb
On 29 April 2016 at 08:31, Andreas Seltenreich wrote:
> Hi,
>
> tonight's sqlsmith run yielded another core dump:
>
> TRAP: FailedAssertion("!(MyProc->lockGroupLeader == ((void *)0))", File:
> "proc.c", Line: 1787)
>
> I couldn't identifiy a query for it though: debug_query_string is empty.
> Add
Amit Kapila wrote:
> On Fri, Apr 29, 2016 at 12:01 PM, Andreas Seltenreich
> wrote:
> > I couldn't identifiy a query for it though: debug_query_string is empty.
> > Additionally, the offending query was not reported in the error context
> > as it typically is for non-parallel executor crashes.
>
On Fri, Apr 29, 2016 at 12:01 PM, Andreas Seltenreich
wrote:
>
> Hi,
>
> tonight's sqlsmith run yielded another core dump:
>
> TRAP: FailedAssertion("!(MyProc->lockGroupLeader == ((void *)0))", File:
"proc.c", Line: 1787)
>
> I couldn't identifiy a query for it though: debug_query_string is empty.
17 matches
Mail list logo