Re: [PATCH] Make jsonapi usable from libpq

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Jacob Champion <pchampion(at)vmware(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se>
Subject: Re: [PATCH] Make jsonapi usable from libpq
Date: 2021-06-28 19:15:47
Message-ID: 335902.1624907747@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhihong Yu 2021-06-28 19:22:17 Re: Rename of triggers for partitioned tables
Previous Message John Naylor 2021-06-28 19:13:06 Re: A qsort template