Re: [PATCH] Make jsonapi usable from libpq

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] Make jsonapi usable from libpq
Дата
Msg-id 3131385.1624746109@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCH] Make jsonapi usable from libpq  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCH] Make jsonapi usable from libpq  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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)".  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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Pipeline mode and PQpipelineSync()
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: Different compression methods for FPI