From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: Jacob Champion <pchampion@vmware.com>,
        "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
        Daniel Gustafsson <daniel@yesql.se>
Subject: Re: [PATCH] Make jsonapi usable from libpq
In-reply-to: <3122443.1624735363@sss.pgh.pa.us>
References: <a250d475ba1c0cc0efb7dfec8e538fcc77cdcb8e.camel@vmware.com>
 <YNQedHwheUaTnnGt@paquier.xyz>
 <daeb22ec6ca8ef61e94d766a9b35fb03cabed38e.camel@vmware.com>
 <YNZ2mnsbDVJQrA/a@paquier.xyz> <3045186.1624729430@sss.pgh.pa.us>
 <3122443.1624735363@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Sat, 26 Jun 2021 15:22:43 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3131384.1624746109.1@sss.pgh.pa.us>
Date: Sat, 26 Jun 2021 18:21:49 -0400
Message-ID: <3131385.1624746109@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3131385.1624746109%40sss.pgh.pa.us>
Precedence: bulk

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)".  The only call sites are in
default_threadlock() (used in fe_auth.c) and pq_lockingcallback()
(for OpenSSL).  I suggest that

1. "fprintf(stderr)" in these locking functions doesn't seem
remarkably well-advised either.  Especially not on Windows;
but in general, we don't expect libpq to emit stuff on stderr
except under *very* limited circumstances.

2. In an assert-enabled build, Assert() ought to be about equivalent
to abort().

3. In a production build, if one of these mutex calls fails, ignoring
the failure might be the best thing to do anyway.  Certainly, dumping
core is the worst possible outcome, while not doing anything would
have no impact except in the rather-unlikely case that multiple libpq
connections try to use this code concurrently.

It's certainly possible to quibble about point 3, but unless you
have a better alternative to offer, I don't think you have a lot
of room to complain.

			regards, tom lane