Re: pgbench: option delaying queries till connections establishment?
Fabien COELHO <coelho@cri.ensmp.fr>
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Marina Polyakova <m.polyakova@postgrespro.ru>,
pgsql-hackers <pgsql-hackers@postgresql.org>, kuroda.hayato@fujitsu.com,
David Rowley <dgrowleyml@gmail.com>
Date: 2021-03-13T11:09:37Z
Lists: pgsql-hackers
Hello Thomas, >> I must say that I'm not a big fan of the macro-based all-in-capitals API >> for threads because it exposes some platform specific uglyness (eg >> THREAD_FUNC_CC) and it does not look much like clean C code when used. I >> liked the previous partial pthread implementation better, even if it was >> not the real thing, obviously. > > But we were using macros already, to support --disable-thread-safety > builds. Yep, but the look and feel was still C code. > I just changed them to upper case and dropped the 'p', because I didn't > like to pretend to do POSIX threads, but do it so badly. Hmmm. From the source code point of view it was just like actually using posix threads, even if the underlying machinery was not quite that on some systems. I value looking at "beautiful" and "standard" code if possible, even if there is some cheating involved, compared to exposing macros. I made some effort to remove the pretty ugly and inefficient INSTR_TIME macros from pgbench, replaced with straightforward arithmetic and inlined functions. Now some other macros just crept back in:-) Anyway, this is just "les goûts et les couleurs" (just a matter of taste), as we say here. > Perhaps we should drop --disable-thread-safety soon, and perhaps it is > nearly time to create a good thread abstraction in clean C code, for use > in the server and here? Then we won't need any ugly macros. +1. >> ISTM that with the current approach threads are always used on Windows, >> i.e. pgbench does not comply to "ENABLE_THREAD_SAFETY" configuration on >> that platform. Not sure whether this is an issue that need to be >> addressed, though. > > The idea of that option, as I understand it, is that in ancient times > there were Unix systems with no threads (that's of course the reason > PostgreSQL is the way it is). I don't think that was ever the case > for Windows NT, and we have no build option for that on Windows > AFAICS. Ok, fine with me. -- Fabien.
Commits
-
Fix new pthread code to respect --disable-thread-safety.
- de91c3b976cf 14.0 landed
-
Add missing pthread_barrier_t.
- 44bf3d5083e1 14.0 landed
-
pgbench: Improve time logic.
- 547f04e7348b 14.0 landed
-
pgbench: Refactor thread portability support.
- b1d6a8f86813 14.0 landed
-
pgbench: Synchronize client threads.
- aeb57af8e640 14.0 landed
-
Fix bogus logic for skipping unnecessary partcollation dependencies.
- 84d514887f9c 12.0 cited