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
|
Список | 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 по дате отправления: