Re: [HACKERS] pg_stat_activity crashes

Hello, thank you for understanding. At Mon, 25 Apr 2016 10:26:49 -0400, Robert Haas wrote in > On Thu, Apr 21, 2016 at 9:47 PM, Kyotaro HORIGUCHI > wrote: > > A lock was

Re: [HACKERS] pg_stat_activity crashes

On Thu, Apr 21, 2016 at 9:47 PM, Kyotaro HORIGUCHI wrote: > A lock was already held in BackendPidGetProc(). Is it also > needless? If so, we should use BackendPidGetProcWithLock() instad > (the name seems a bit confusing, though). Oh, that's really sad. No, that

Re: [HACKERS] pg_stat_activity crashes

At Thu, 21 Apr 2016 14:05:28 -0400, Robert Haas wrote in > >>> Here is PoC patch which fixes the problem. I am wondering if we should > >>> raise warning in the pg_stat_get_backend_wait_event_type() and >

Re: [HACKERS] pg_stat_activity crashes

On Thu, Apr 21, 2016 at 2:04 PM, Robert Haas wrote: > On Wed, Apr 20, 2016 at 10:56 PM, Kyotaro HORIGUCHI > wrote: >> At Wed, 20 Apr 2016 15:14:16 +0200, Petr Jelinek >> wrote in <571780a8.4070...@2ndquadrant.com>

Re: [HACKERS] pg_stat_activity crashes

On Wed, Apr 20, 2016 at 10:56 PM, Kyotaro HORIGUCHI wrote: > At Wed, 20 Apr 2016 15:14:16 +0200, Petr Jelinek wrote > in <571780a8.4070...@2ndquadrant.com> >> I noticed sporadic segfaults when selecting from pg_stat_activity on >> current

Re: [HACKERS] pg_stat_activity crashes

Hello, At Wed, 20 Apr 2016 15:14:16 +0200, Petr Jelinek wrote in <571780a8.4070...@2ndquadrant.com> > I noticed sporadic segfaults when selecting from pg_stat_activity on > current HEAD. > > The culprit is the 53be0b1add7064ca5db3cd884302dfc3268d884e commit > which added

[HACKERS] pg_stat_activity crashes

Hi, I noticed sporadic segfaults when selecting from pg_stat_activity on current HEAD. The culprit is the 53be0b1add7064ca5db3cd884302dfc3268d884e commit which added more wait info into the pg_stat_get_activity(). More specifically, the following code is broken: +