Re: [sqlsmith] Failed assertion in BecomeLockGroupLeader
От | Andreas Seltenreich |
---|---|
Тема | Re: [sqlsmith] Failed assertion in BecomeLockGroupLeader |
Дата | |
Msg-id | 87bn4sey8p.fsf@credativ.de обсуждение исходный текст |
Ответ на | Re: [sqlsmith] Failed assertion in BecomeLockGroupLeader (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: [sqlsmith] Failed assertion in BecomeLockGroupLeader
Re: [sqlsmith] Failed assertion in BecomeLockGroupLeader |
Список | 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 по дате отправления: