Re: pgsql: Refactor dlopen() support

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pgsql: Refactor dlopen() support
Дата
Msg-id 14508.1536301857@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: pgsql: Refactor dlopen() support  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Refactor dlopen() support

Buildfarm member locust doesn't like this much.  I've been able to
reproduce the problem on an old Mac laptop running the same macOS release,
viz 10.5.8.  (Note that we're not seeing it on earlier or later releases,
which is odd in itself.)  According to my machine, the crash is happening
here:

#0  _PG_init () at plpy_main.c:98
98              *plpython_version_bitmask_ptr |= (1 << PY_MAJOR_VERSION);

and the reason is that the rendezvous variable sometimes contains garbage.
Most sessions correctly see it as initially zero, but sometimes it
contains

(gdb) p plpython_version_bitmask_ptr
$1 = (int *) 0x1d

and I've also seen

(gdb) p plpython_version_bitmask_ptr
$1 = (int *) 0x7f7f7f7f

It's mostly repeatable but not completely so: the 0x1d case seems
to come up every time through the plpython_do test, but I don't
always see the 0x7f7f7f7f case.  (Maybe that's a timing artifact?
It takes a variable amount of time to recover from the first crash
in plpython_do, so the rest of the plpython test run isn't exactly
operating in uniform conditions.)

No idea what's going on here, and I'm about out of steam for tonight.

            regards, tom lane


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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Collation versioning
Следующее
От: David Rowley
Дата:
Сообщение: Small performance tweak to run-time partition pruning