pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Jacob Champion <pchampion@vmware.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Cc: Daniel Gustafsson <daniel@yesql.se>
Subject: Re: [PATCH] Make jsonapi usable from libpq
Date: Sat, 26 Jun 2021 18:21:49 -0400
Message-ID: <3131385.1624746109@sss.pgh.pa.us> (raw)
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>

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





view thread (21+ messages)  latest in thread

Message-ID: <3131385.1624746109@sss.pgh.pa.us>
Permalink:  ../3131385.1624746109@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/3131385.1624746109@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, michael@paquier.xyz, pchampion@vmware.com, daniel@yesql.se
  Subject: Re: [PATCH] Make jsonapi usable from libpq
  In-Reply-To: <3131385.1624746109@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox