Re: [HACKERS] [sqlsmith] Crash reading pg_stat_activity

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: [HACKERS] [sqlsmith] Crash reading pg_stat_activity
Дата
Msg-id CAEepm=2daDTjRQQptRMTspzn98YgqwkpEspXkuYdC+tQp9ujEg@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] [sqlsmith] Crash reading pg_stat_activity  (Andreas Seltenreich <seltenreich@gmx.de>)
Ответы Re: [HACKERS] [sqlsmith] Crash reading pg_stat_activity  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список pgsql-hackers
On Wed, Dec 28, 2016 at 10:01 AM, Andreas Seltenreich
<seltenreich@gmx.de> wrote:
> testing master as of fe591f8bf6 produced a crash reading
> pg_stat_activity (backtrace below).  Digging around with with gdb
> revealed that pgstat_get_wait_event() returned an invalid pointer for a
> classId PG_WAIT_LWLOCK.
>
> I think the culprit is dsa.c passing a pointer to memory that goes away
> on dsa_free() as a name to LWLockRegisterTranche.

I see, nice detective work!

dsa.c's create_internal and attach_internal call LWLockRegisterTranche
with a pointer to a name in a DSM segment (copied from an argument to
dsa_create), which doesn't have the right extent in this rare race
case: the DSM segment goes away when the last backend detaches, but
after you've detached you might still see others waiting for a lock
that references that tranche ID in pg_stat_activity.  This could be
fixed by copying the tranche name to somewhere with backend lifetime
extent in each backend, but then that would need cleanup.  Maybe we
should replace it with another value when the DSA area is detached,
using a constant string.  Something like
LWLockRegisterTranche(tranche_id, "detached_dsa").  That would be a
new use for the LWLockRegisterTranche function, for
re-registering/renaming and existing tranche ID.  Thoughts?

-- 
Thomas Munro
http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andreas Seltenreich
Дата:
Сообщение: [HACKERS] [sqlsmith] Crash reading pg_stat_activity
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: [HACKERS] pg_stat_activity.waiting_start