Re: pgsql: Refactor dlopen() support
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2018-09-07T06:30:57Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Work around stdbool problem in dfmgr.c.
- ff47d4bf1f20 12.0 landed
-
Refactor dlopen() support
- 842cb9fa62fc 12.0 cited
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