Re: pgbench: option delaying queries till connections establishment?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Fabien COELHO <coelho@cri.ensmp.fr>,
Marina Polyakova <m.polyakova@postgrespro.ru>,
pgsql-hackers <pgsql-hackers@postgresql.org>,
kuroda.hayato@fujitsu.com, David Rowley <dgrowleyml@gmail.com>
Date: 2021-03-13T02:46:46Z
Lists: pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes: > On Mon, Mar 8, 2021 at 3:18 PM Thomas Munro <thomas.munro@gmail.com> wrote: >> David Rowley kindly tested this for me on Windows and told me how to >> fix one of the macros that had incorrect error checking on that OS. >> So here's a new version. I'm planning to commit 0001 and 0002 soon, >> if there are no objections. 0003 needs some more review. > I made a few mostly cosmetic changes, pgindented and pushed all these patches. So, gaur is not too happy with this: ccache gcc -std=gnu99 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -O2 -I../../src/port -DFRONTEND -I../../src/include -D_USE_CTYPE_MACROS -D_XOPEN_SOURCE_EXTENDED -I/usr/local/libxml2-2.6.23/include/libxml2 -I/usr/local/ssl-1.0.1e/include -c -o strlcat.o strlcat.c pthread_barrier_wait.c: In function 'pthread_barrier_init': pthread_barrier_wait.c:24:2: error: incompatible type for argument 2 of 'pthread_cond_init' /usr/include/pthread.h:378:5: note: expected 'pthread_condattr_t' but argument is of type 'void *' pthread_barrier_wait.c:26:2: error: incompatible type for argument 2 of 'pthread_mutex_init' /usr/include/pthread.h:354:5: note: expected 'pthread_mutexattr_t' but argument is of type 'void *' make[2]: *** [pthread_barrier_wait.o] Error 1 Checking the man pages, it seems that this ancient HPUX version is using some pre-POSIX API spec in which pthread_cond_init takes a pthread_condattr_t rather than a pointer to pthread_condattr_t. Similarly for pthread_mutex_init. While it's likely that we could work around that, it's my opinion that we shouldn't have to, because gaur is building with --disable-thread-safety. If that switch has any meaning at all, it should be that we don't try to use thread infrastructure. Was any thought given to being able to opt out of this patchset to support that configure option? regards, tom lane
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