Re: [sqlsmith] Failed assertion in BecomeLockGroupLeader - Mailing list pgsql-hackers

From Andreas Seltenreich
Subject Re: [sqlsmith] Failed assertion in BecomeLockGroupLeader
Date
Msg-id 87bn4sey8p.fsf@credativ.de
Whole thread Raw
In response to Re: [sqlsmith] Failed assertion in BecomeLockGroupLeader  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [sqlsmith] Failed assertion in BecomeLockGroupLeader  (Andres Freund <andres@anarazel.de>)
Re: [sqlsmith] Failed assertion in BecomeLockGroupLeader  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
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 should be able to attach to that process and get another
> stack trace.  I'm curious on whether you would need to have started
> the server with "postgres -T"

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 text for syscache lookups and triggering
an NAMEDATALEN assertion.

E.g.: select has_language_privilege('smithsmithsmithsmithsmithsmithsmithsmithsmithsmithsmithsmithsmith', smith');

thanks,
andreas



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: atomic pin/unpin causing errors
Next
From: Andreas Seltenreich
Date:
Subject: Re: [sqlsmith] Failed assertion in BecomeLockGroupLeader