Re: pgsql: Refactor dlopen() support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Refactor dlopen() support
Date: 2018-09-07 14:19:06
Message-ID: 3574.1536329946@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 07/09/2018 08:30, Tom Lane wrote:
>> 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.)

> Nothing should have changed on macOS except that the intermediate
> functions pg_dl*() were replaced by direct calls to dl*(). Very strange.

Somehow or other, the changes you made in dfmgr.c's #include lines
have made it so that find_rendezvous_variable's local "bool found"
variable is actually of type _Bool (which is word-wide on these
machines). However, hash_search thinks its output variable is
of type pointer to "typedef char bool". The proximate cause of
the observed failure is that find_rendezvous_variable sees "found"
as true when it should not, and thus fails to zero out the variable's
value.

No time to look further right now, but there's something rotten
about the way we're handling bool.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Eisentraut 2018-09-07 16:27:28 Re: pgsql: Refactor dlopen() support
Previous Message Andrew Gierth 2018-09-07 13:40:07 pgsql: Refactor installation of extension headers.

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2018-09-07 14:28:00 Re: [HACKERS] proposal: schema variables
Previous Message Peter Eisentraut 2018-09-07 13:57:01 Re: Removing useless \. at the end of copy in pgbench