I wrote:
>> Not real sure what to do about PGTHREAD_ERROR.
> I wonder if we shouldn't simply nuke that macro and change the
> call sites into "Assert(false)".
After further study this still seems like the best available choice.
We do not have the option to make either default_threadlock() or
pq_lockingcallback() do something saner, like return a failure
indication. pq_lockingcallback()'s API is dictated by OpenSSL,
while default_threadlock()'s API is exposed to users by libpq
(IOW, we could have gotten that one right years ago, but we
failed to, and it seems much too late to change it now).
Also, I trawled the mailing list archives, and I can find no
indication that any of the PGTHREAD_ERROR messages have ever
been seen in the field. The last relevant discussion seems
to be in
https://www.postgresql.org/message-id/flat/20130801142443.GO2706%40tamriel.snowman.net
where it was observed that this code isn't very well thought
through :-(
My proposal is to replace PGTHREAD_ERROR by Assert(false)
in HEAD, but leave things alone in the back branches.
As far as the other patch to check for mistakes with "nm"
goes, we could either do nothing in the back branches, or
install a check for "exit" only, not "abort". But there's
probably no real need for such a check in the back branches
as long as we're enforcing it in HEAD.
regards, tom lane
