Pr/postgre sql in taf - #7
Conversation
|
Thank you! I will put full effort in going through, and getting merged. Seriously, thank you for this contribution. |
|
@JonathanBMiller Oh, you're welcome :-). See more info and background for these changes in a mail I sent you few minutes ago. Looking forward for cooperation. |
|
Hi Lukas, This branch looks good, but it’s not based on the latest TAF main. Would you please rebase it with current main so the diff is clean and I can review it properly? These are some of the changes that will impact PG plugin. Best, |
- Added PostgreSQL database plugin (libs/db/postgresql.pm) - Added PostgreSQL-specific benchmark configs and test suite entries - Fixed schema public permission issue in PostgreSQL benchmarks - Fixed remaining Czech comments; all comments now in English Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Run.pm: fix Executor->import(':all') to sql_libs::Executor->import(':all')
(bare Executor wasn't a resolvable package name).
- setup_almalinux10.sh (appstream method): install postgresql-server +
libpq-devel with --allowerasing instead of postgresql-server-devel, which
conflicts with libpq-devel via postgresql-private-devel on EL10. Fall back
to hardcoded AppStream include/lib paths when pg_config (shipped by
postgresql-server-devel) isn't available.
- sysbench build: force a fresh --recurse-submodules clone whenever the
LuaJIT submodule Makefile is missing (a zip-extracted source tree has no
.git, so submodules are silently empty); invoke autogen.sh/configure via
`bash` explicitly since files from a zip may lack the executable bit.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…s OS user Root cause of a campaign-wide failure: --method=percona (tarball) never created the "postgres" OS user, unlike the appstream/pgdg RPM packages (their %pre scriptlet does it automatically). postgres.pm's constructor requires an OS user literally named "postgres" to drop root privileges before running initdb -- PostgreSQL refuses to run as root -- so every initdb failed with "cannot be run as root". Now creates the group+user (system account, home /var/lib/pgsql) unconditionally before any install method runs; a no-op if the RPM path already created it. Also: - EXPECTED_PG_VERSION="18.4" pinned at the top; new step 3b hard-fails setup if the installed `postgres --version` doesn't match exactly, across all three --method installers, instead of silently running benchmarks against an unintended version. - install_percona_tarball(): VERSION 16.14 -> 18.4; corrected OpenSSL-tag detection for PG18's 3-way tarball split (ssl1.1/ssl3/ssl3.5 by major.minor, not PG16's 2-way ssl1/ssl3 by major only) -- these guests run OpenSSL 3.5.x, which needs ssl3.5 specifically. - install_pgdg_rpm()/install_appstream(): postgresql16-* -> postgresql18-* package names and PG_INSTALL_DIR paths. - PERCONA_LOCAL_ARCHIVE: skip the downloads.percona.com fetch when taf_manage.py has already SCP'd a tarball here (--PERCONA_ARCHIVE_LOCAL), avoiding N guests hitting Percona's download server at once. Verified live: postgres (PostgreSQL) 18.4 - Percona Server for PostgreSQL 18.4.1, full sysbench build + benchmark run succeeded end-to-end.
…uning postgresql_default.conf: new stock-defaults reference profile for PostgreSQL 18.4 (TAF/tests/setup_almalinux10.sh's EXPECTED_PG_VERSION). Every setting is commented out with its PG18 default value and a doc link, so diffing against it shows exactly what postgresql_oltp.conf/_analytics.conf override and by how much. Documents the "mandatory parameters" question directly: no postgresql.conf setting actually lacks a built-in default (initdb generates a fully valid one); the only non-stock values a run gets are the ones TAF forces regardless of db_config_file (port, listen_addresses, ssl). Now the active taf.db_config_file in both .properties files (previously postgresql_oltp.conf), so a plain run_me.sh invocation benchmarks against stock PG18 settings unless a tuned profile is selected explicitly. postgresql_oltp.conf / postgresql_analytics.conf: add an I/O Workers section (io_method=worker, io_workers=16, up from the PG18 stock default of 3) -- PG18's new async-I/O worker pool is the direct answer to "how many IO threads does a run use" now that we're off PG16 (which had no such pool; effective_io_concurrency there was just an advisory prefetch depth). All four .conf files: updated header comments to note the PG18.4 target version and reference postgresql_default.conf for the stock-default diff.
…against fleet-scale flakiness - oltp_skip_trx=on, number_of_tables=8 to match MariaDB's effective values (see mariadb-vs-postgresql-taf-test-implementaion-differences.md) - Retry sysbench git clone (3x with backoff) instead of failing the whole host on a single transient network error at 200+-host fan-out - Clear config.cache before configure: a stale cache from a killed/retried build was poisoning checks (observed: bogus "thread-local storage not supported" from a cached "checking for stdlib.h... (cached) no") Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Interpreting a TAF run's actual behavior requires reconstructing what default properties, user properties, and CLI overrides resolved to -- none of that merged state was ever visible anywhere. This dumps %options/%dirs/%files plus %ENV to STDERR as a YAML-comment block (4 spaces per level, "# key: value") so it can be pasted straight into a result.yaml as documentation, redacting password-shaped keys (case-insensitive match on AUTH/COOKIE/CREDENTIAL/PASS/PWD/PRIVATE/ SECRET/TOKEN, not just an exact-key list, so PGPASSWORD/MYSQL_PWD-style env vars are caught too).
sysbench_lua.db_driver=mariadb normalizes to "mysql", but was compared against the properties-file value verbatim (only lowercased, never normalized), so a correctly configured MariaDB run always failed with "Mismatch: sysbench_lua.db_driver = mariadb, db install shows mariadb (normalized: mysql)" -- discovered running the MariaDB pipeline against a freshly built local TAF.zip for the first time.
…p with pgsql taf.threads was 4,8,16,32,64,128 here vs 8,16,32,64,128 in properties/postgresql/sysbench_lua_pgsql.properties -- the extra low-end data point was the last remaining mismatch in the thread sweep between the two engines' example configs. Also strips trailing whitespace from the license header.
…r too
SetConnectionArgs() always hardcoded --pgsql-host='127.0.0.1' for
PostgreSQL, ignoring taf.db_clients_use_unix_socket (which defaults to
true and already takes effect for MySQL/MariaDB via --mysql-socket) --
so PostgreSQL runs always went over TCP loopback while MariaDB runs
went over a unix socket, a client-connection asymmetry irrelevant to
the workload itself but not to measured latency/throughput.
drv_pgsql.c passes --pgsql-host straight into PQsetdbLogin(), and libpq
treats a value starting with '/' as a unix-socket directory rather
than a hostname (unlike libmysqlclient, where "localhost" already
implies socket use) -- so this has to be requested with an explicit
path, not by omitting the flag. pg_hba.conf already allows it ("local
all all md5", postgres.pm::_db_write_pg_hba_conf), and
taf_run_pgsql.sh already assumes /var/run/postgresql is writable for
the server's socket, so that path is reused as the default here
(overridable via taf.db_socket). The port is still passed alongside
the socket path since libpq derives the socket filename
(.s.PGSQL.<port>) from host dir + port.
…stgresql_default.conf Every line commented out, documenting MariaDB 12.2.2's upstream default for each setting also tuned by mariadb_cache.cnf / mariadb_simple_2gbp.cnf / mariadb_tidesdb*.cnf, plus a KB doc link per setting -- gives the two engines a directly comparable "everything stock" baseline for workload equivalence testing, the same role postgresql_default.conf already plays for PostgreSQL.
mariadbd unconditionally refuses to start as root (no --allow-run-as-root override), so taf_run.sh hard-refused root outright rather than actually handling it -- this broke MariaDB density campaigns on infrastructure where the SSH/provisioning user is root throughout (e.g. the Plovdiv vSAN pool, where PostgreSQL campaigns already work fine because postgres.pm handles root by dropping to the 'postgres' OS user via runuser). Add the same handling here: detect EUID 0 in the constructor, resolve (or create, since this targets a tarball install with no package postinstall script to have created one already) a 'mysql' system user, and run mariadb-install-db/mariadbd via runuser -u mysql -- through a new _os_prefix() helper. Also chowns data_dir and tmpdir to that user in _db_prepare_data_dir(), since mariadbd itself opens the socket/pidfile/log-error paths under tmpdir. taf_run.sh's hard root guard removed in a companion mt-qa-tools.vhistrg commit now that the plugin handles it.
_db_prepare_data_dir()'s root-handling chowned only the tmpdir entry itself, not its contents. data_dir is wiped and recreated from scratch every run, so it's never an issue there, but tmpdir persists across attempts -- a bootstrap/runtime pidfile or log left behind by an earlier failed attempt (e.g. one that predates this root-handling, or one that failed before reaching this chown) stays owned by root, and mariadbd (now running as 'mysql' via runuser) fails outright when it can't create/write its own --pid-file over an existing root-owned one. Confirmed via a real failure on the Plovdiv density-curve verification: InnoDB started fine as 'mysql', then died on "Can't create/write to file '.../mariadb_bootstrap.pid' (Errcode: 13)".
…t/mysql ownership race _spawn_background()'s parent (always root, never drops privileges) writes the same --pid-file= path that mariadbd itself (running as 'mysql' via runuser/_os_prefix() after this session's earlier fix) also writes internally. Whichever of the two creates the file first owns it; root's write happens first in practice (~1s after fork, right around when mariadbd finishes InnoDB init and attempts its own pid-file write), so mariadbd's later write failed with "Can't create/write to file ... Permission denied" and the server died -- confirmed via a real failure on the Plovdiv density-curve verification, past the point the previous two fixes (root detection, recursive tmpdir chown) got it to. Pre-creating and chowning the pidfile to the target OS user before forking means both writers just open an *existing* file (which doesn't change ownership) instead of racing to create it, regardless of order.
MariaDB's config parser rejects a file with no section headers at all
("Config file contains no section headers"), even when every setting
under that section is commented out -- unlike postgresql_default.conf,
which needs no section header since postgresql.conf has no sections.
Confirmed via a real failure (TAF Exit Code: 1) using this file as
taf.db_config_file on the Plovdiv verification.
…on, and $_me:: log interpolation
PostgreSQL sysbench connections were failing with "connection to server
on socket ".../db.sock/.s.PGSQL.<port>" failed: No such file or
directory": sysbench-lua.pm passed the raw db_socket file path (e.g.
"<tmp_dir>db.sock") as --pgsql-host, but libpq treats that value as a
unix-socket *directory* and appends ".s.PGSQL.<port>" itself. postgres.pm
never configured unix_socket_directories either, so PostgreSQL was left
listening at its own stock default (/tmp), which never matched anyway.
Fix: postgres.pm now sets unix_socket_directories to the same tmpdir
TAF already manages; sysbench-lua.pm passes dirname($options{db_socket})
as --pgsql-host instead of the raw file-shaped path, so the two agree.
Separately, both engines' "is sysbench already built" checks (taf_run.sh
for MariaDB, setup_almalinux10.sh for PostgreSQL) only checked that a
sysbench binary/symlink existed, not which database driver it was built
with. Running one engine after the other against the same guest (shared
client_source/sysbench-lua/ tree) left a binary built for the wrong
driver in place, and the second engine's sysbench prepare/run failed
immediately with "invalid option: --mysql-socket=..." or the pgsql
equivalent. setup_almalinux10.sh now verifies the driver via
`sysbench <script> --help` before trusting an existing binary.
Also fixed a latent bug in postgres.pm/mariadb.pm's own log tags: strings
written as "$_me::something" are parsed by Perl as the fully-qualified
variable ${_me::something} (undefined), not $_me followed by literal
"::something" -- silently dropping the log prefix and tripping "Use of
uninitialized value" warnings on every DB lifecycle call. Changed to
"${_me}::something" throughout both files (11 + 4 occurrences).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
769a6ca to
8cd7add
Compare
|
Hi Jeb,
Sure and sorry for delay. It should already be there. Do you want to have it squashed too for convenience?
Best regards
Lukas Oliva
[cid:d325e84c-4595-47a8-8806-2a7959bd9e07]
…________________________________
Od: Jonathan Miller ***@***.***>
Odesláno: pondělí 27. července 2026 19:12
Komu: MariaDB/TAF ***@***.***>
Kopie: Lukas Oliva ***@***.***>; Author ***@***.***>
Předmět: Re: [MariaDB/TAF] Pr/postgre sql in taf (PR #7)
[https://avatars.githubusercontent.com/u/228399023?s=20&v=4]JonathanBMiller left a comment (MariaDB/TAF#7)<#7 (comment)>
Hi Lukas,
This branch looks good, but it’s not based on the latest TAF main.
Would you please rebase it with current main so the diff is clean and I can review it properly?
Best,
/Jeb
—
Reply to this email directly, view it on GitHub<#7?email_source=notifications&email_token=CJ3IKOI4RLQSTUNNESKIW3L5G6EO5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBZGQ2DCMRVGQ3KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5094412546>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/CJ3IKOO5GSXKTUVAREJA5R35G6EO5AVCNFSNUABGKJSXA33TNF2G64TZHMYTCNBSGM4TCMBTHE5US43TOVSTWNBZHA4TEMRWG42TTILWAI>.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/CJ3IKOJTFOCQYRRKNH6R53L5G6EO5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBZGQ2DCMRVGQ3KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android<https://github.com/notifications/mobile/android/CJ3IKOP47H3VI44U5WP373D5G6EO5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBZGQ2DCMRVGQ3KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today!
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Thank you! Time for me to get to work :-) |
|
Lukas, Thank you — and thank you to Virtuozzo for supporting the work. Below is the initial review. I have not tested any of it yet; I’m starting that now. I will update the PR with findings from my testing. If you have questions, or think I missed something, please let me know. Review is below, updated files attached. Best,
Added support for dumping the fully resolved TAF configuration to a file. Changes:
Usage additions: O = --debug-print-config O = --debug-print-config-path=/path/to/dump/ Files touched:
I think this directory would be confusing to other as "tests" actually are "properties" Please create directory postgresql_related under taf-perl/scripts and move scripts/shells there. eg. taf-perl/scripts/postgresql_related
Both sysbench and tpcc properties look fine.
no issues...
Executor.pm:
sql_libs/dialects/postgres.sql
taf-perl/libs/sql_libs/postgres.sql ??? Why is this there?
There were serval changes needed..(attached updated pm)
All PostgreSQL root-handling code has been removed. The framework will not allow execution under UID 0, and PostgreSQL now follows that policy with no Why root cannot be allowed for benchmarking:
With root user not being allowed, please restore mariadb.pm to the current main version, removing all root-user-specific code.
|
|
Hi Lukas, Have just had time to move to test host, and start functional testing on my side. libs/taf_libs/TAF/Utilities.pm Missing semi at end of line 1617 TAF Configuration dump pathWill let you know if I find other issues in my work, or overall. Thanks, |
|
Hi Lukas, Worked on getting the PG install internal to TAF correct, along with pg init, start, and stop. eg. perl taf.pl --db-software-install --db-software-install-packages=/home/jeb/pg18-rpms/postgresql18-server-18.4-2PGDG.rhel9.8.x86_64.rpm,/home/jeb/pg18-rpms/postgresql18-libs-18.4-2PGDG.rhel9.8.x86_64.rpm,/home/jeb/pg18-rpms/postgresql18-18.4-2PGDG.rhel9.8.x86_64.rpm,/home/jeb/pg18-rpms/postgresql18-contrib-18.4-2PGDG.rhel9.8.x86_64.rpm _SelectBasePackage -> server-capable package: /home/jeb/pg18-rpms/postgresql18-server-18.4-2PGDG.rhel9.8.x86_64.rpm (found postgres) DatabaseSoftwareInstalls::_CreateTempStagingDir -> Created staging dir: /tmp/taf_unpack_1487387_1785965167 Install has completed. Happy benchmarking! [jeb@hz-bench-jeb taf-dev]$ ls database_software_installs/ database_software_installs/postgresql18-server-18.4-2PGDG.rhel9.8.x86_64/doc/: database_software_installs/postgresql18-server-18.4-2PGDG.rhel9.8.x86_64/etc/: database_software_installs/postgresql18-server-18.4-2PGDG.rhel9.8.x86_64/lib/: [jeb@hz-bench-jeb taf-dev]$ perl taf.pl --list-database-software-installs == AVAILABLE DATABASE SOFTWARE INSTALLS =================== [ACTIVE] 1: /home/jeb/taf-dev/database_software_installs/postgresql18-server-18.4-2PGDG.rhel9.8.x86_64 perl taf.pl --prop=properties/postgresql/sysbench_lua_pgsql.properties --action=init-start-db-exit --verbose
|
|
In the process of trying to run sysbench against PostgreSQL, I hit multiple third‑party build failures inside the sysbench tree. These were not PG issues; they were missing or mis‑ordered third‑party components that prevented a clean sysbench build. I addressed those in commit 623f553 I recommend merging the latest TAF to pick up those fixes before reviewing this PG work. After pulling in the updated and merging the test suite, sysbench would compile with WITH_PGSQL, but the PostgreSQL driver was still not being built or linked. The PG driver was never added to the build graph, never registered, and never linked into the final sysbench binary. The attached cmakelist.txt.tar.gz contains two CMakeLists.txt files: CMakeLists.txt_sysbench
CMakeLists.txt_drivers_pgsql New file under src/drivers/pgsql that:
With these changes, and with the updated test suite merged in, sysbench now correctly includes the PostgreSQL driver. Example output: =============== --percentile=N percentile to calculate in latency statistics (1-100). Use the special value of 0 to disable percentile calculations [95] General database options: --db-driver=STRING specifies database driver to use ('help' to get list of available drivers) Compiled-in database drivers: pgsql options: Compiled-in tests:
|
|
Hi Lukas, During the first review pass I noticed how rough the sysbench build logic was. It’s been bothering me since that initial look, and honestly it should have been cleaned up during TAF’s beta. Yesterday afternoon and evening I finally made time to rewrite it properly. The attached tar.gz contains the updated files: CMakeLists.txt – major rewrite ClientCmakeBuild.pm – rewritten to match the new deterministic build sysbench_lua_default.properties – removed obsolete -DWITH_(maker) flags With these changes, users can now build sysbench using either MariaDB or PostgreSQL cleanly, without special flags or hacks. The build system is deterministic, contributor‑proof, and aligned with the PG work Virtuozzo has been pushing in TAF. Let me know if you want any adjustments. perl ./taf.pl --prop=properties/postgresql/sysbench_lua_pgsql.properties --verbose --action=build-client --tools-debug General database options: --db-driver=STRING specifies database driver to use ('help' to get list of available drivers) Compiled-in database drivers: pgsql options: perl taf.pl --set-active-database-software-install [ACTIVE] 2: /home/jeb/taf-dev/database_software_installs/postgresql18-server-18.4-2PGDG.rhel9.8.x86_64 [ACTIVE] 1: /home/jeb/taf-dev/database_software_installs/mariadb-bb‑12.3‑av‑perf‑3 perl taf.pl --prop=properties/mariadb/beta/sysbench_lua.properties --verbose --action=build-client --tools-debug General database options: --db-driver=STRING specifies database driver to use ('help' to get list of available drivers) [mysql] Compiled-in database drivers: mysql options: |
|
Hi again,
You're truly welcome. It's a rare pleasure to learn from another performance engineer. I went through your comments and mails and I try to understand the problems you've been having with building sysbench with PostgreSQL support. Can you be more specific about the platform (Linux distro and version) you used for these tests? I haven't noticed these details. Also, to be on the same page, please check what remains to be done. It is to:
*
rebase to the latest TAF
*
apply the changes you sent me
*
verify the complete workflow including all the subcommand combinations on the target platform/version
Am I right?
Best regards
Lukas Oliva
[cid:ac591869-db9e-4ecc-b499-e734dd1961a2]
…________________________________
Od: Jonathan Miller ***@***.***>
Odesláno: pondělí 27. července 2026 17:39
Komu: MariaDB/TAF ***@***.***>
Kopie: Lukas Oliva ***@***.***>; Author ***@***.***>
Předmět: Re: [MariaDB/TAF] Pr/postgre sql in taf (PR #7)
[https://avatars.githubusercontent.com/u/228399023?s=20&v=4]JonathanBMiller left a comment (MariaDB/TAF#7)<#7 (comment)>
Thank you! I will put full effort in going through, and getting merged. Seriously, thank you for this contribution.
—
Reply to this email directly, view it on GitHub<#7?email_source=notifications&email_token=CJ3IKOOOLUEVX2B2WPOZ3Y35G5ZU3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBZGM2DENZYGY4KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5093427868>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/CJ3IKOLAIIJ3EYZT36M36RL5G5ZU3AVCNFSNUABGKJSXA33TNF2G64TZHMYTCNBSGM4TCMBTHE5US43TOVSTWNBZHA4TEMRWG42TTILWAI>.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/CJ3IKOLPTOU3RTRP6WOMTM35G5ZU3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBZGM2DENZYGY4KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android<https://github.com/notifications/mobile/android/CJ3IKOIJP7BN2KAXLFICADD5G5ZU3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBZGM2DENZYGY4KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today!
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Hi Lukas, Since this pull request, the main has had 2 updates.
So merging in current master will allow you to test, and update PR without issue. I have updated the PR request with several changed source files to help the PG project along. I suggest you diff with what you have, so you can see and understand changes made. This last upload around sysbench building with either MariaDB Family or PG was needed badly. Once you have updated, and verified all works to your satisfaction, please resubmit. If you have issues, questions, etc... Please contact me, post here, Best, https://mariadb.org/mariadb-foundation-advances-taf-with-hammerdb-6-0-and-xt_reservoir-integration/ |
The tmp_dir fallback for --pgsql-host concatenated the directory and "db.sock" without a "/", producing e.g. "/tmpdb.sock" instead of "/tmp/db.sock". Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…tgreSQL TAF and pytest now run PostgreSQL as the same non-root user by default, so the cleanup fixture no longer needs su/root to run pg_ctl stop. Only fall back to su when the harness itself is running as root (EUID 0), since pg_ctl unconditionally refuses to operate as root. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Per review feedback, PostgreSQL must not be allowed to run as root, and the root-detection/user-switch mechanism should follow the same pattern already used by mariadb.pm rather than a separate, ad-hoc one: - Auto-create the 'postgres' OS user via useradd when it's missing, instead of silently falling back to running as root (the previous fail-open behavior defeated the entire point of the check). - Drop the /root path relocation logic (data_dir/tmp_dir moved to /tmp/taf_pg_$$) in favor of chowning paths in place, matching mariadb.pm. - chown tmpdir recursively, not just the top-level directory, since it persists across runs and can accumulate root-owned files from earlier attempts -- same rationale as mariadb.pm's tmpdir fix. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
runuser (invoked via _os_prefix() when TAF runs as root) aborts outright if
it can't stat/chdir back to the shell's inherited cwd, even though that
directory is never actually used by postgres/mariadbd. TAF's own working
directory is commonly a root-owned checkout (e.g. /root/taf), which the
target OS user has no traversal rights into -- discovered by running the
full init/start/ping/stop cycle as root on a real host.
/tmp is always world-traversable, so hop there first: prepend "cd /tmp &&"
in postgres.pm's _run_command/_pg_ctl_status and mariadb.pm's _run_command
(both build a shell string), and chdir('/tmp') in the forked child before
exec() in mariadb.pm's _spawn_background (which execs directly, no shell).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
@JonathanBMiller I tried to solve your review and mail comments. Let me know how to proceed. |
The sysbench CMake build never actually wired up the pgsql driver: no option(WITH_PGSQL...) was declared, no WITH_PGSQL->USE_PGSQL conversion existed, and the (dead, since USE_PGSQL was always unset) USE_PGSQL block carried a FATAL_ERROR on UNIX left over from when PG support was Windows-only. Separately, ClientCmakeBuild.pm's _SetLibAndInclude_PostgreSQL resolved pg_config's include/lib dirs but Build() never turned that into -DWITH_PGSQL=ON or passed PGSQLH_PATH/LIBPGSQL_LIB to cmake -- it unconditionally appended only MySQL-specific flags, so the driver was never requested regardless of the CMakeLists.txt issue above. Replaces client_source/sysbench-lua/CMakeLists.txt and libs/script_tools_lib/ClientCmakeBuild.pm with Jonathan Miller's tested rewrite (review/round-1/_mails/2026-08-14-2/sysbench_build_redo/), which fixes both: a uniform WITH_*->USE_* pattern for all drivers, and per-maker dispatch in ClientCmakeBuild.pm (_SetupForPGBuild/_SetupForMariaDBFamilyBuild) that sets the right WITH_* and *H_PATH/*_LIB flags for whichever maker is being built. Adds the missing src/drivers/pgsql/CMakeLists.txt (mirroring src/drivers/mysql/'s) that defines the sbpgsql static library -- without it, add_subdirectory(src/drivers/pgsql) had nothing to build. Drops sysbench_lua_default.properties' static "-DWITH_MYSQL=on -DWITH_PGSQL=on", now redundant and misleading since ClientCmakeBuild.pm sets both flags itself, correctly, per build. One correction on top of the imported patch: _SetupForPGBuild required a postgres.h server header that drv_pgsql.c never includes (it only uses libpq-fe.h, being a libpq client, not a server-side extension) -- dropped that check so the build doesn't need postgresql-server-devel-style packages, only the libpq client headers. Verified locally in an isolated AlmaLinux 9 podman container (no shared/ reserved hosts touched): cmake configure shows USE_PGSQL=1 and "Adding pgsql db driver" with no FATAL_ERROR, sysbench links against libpq.so and lists the pgsql driver, and a real prepare + oltp_read_only run against a local PostgreSQL 13 instance completes successfully (2514 tps). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…res.sql libs/sql_libs/postgres.sql was a near-identical duplicate of libs/sql_libs/dialects/postgres.sql (missing only the copyright line and a trailing newline) with zero references anywhere in the codebase -- an accidental leftover, not a second copy anyone depends on. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Follow-up to ed31384, which only committed the postgres.sql removal -- this adds the "# Version: 4.0" header line itself. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…file
Per review feedback, the config dump belongs in TAF::Logging as
PrintTafConfigToFile($ctx), not as a taf.pl-local sub -- and per the
original design, output goes to a timestamped file
(taf_configuration_dump_YYYYMMDD_HHMMSS.txt), not STDERR, so it survives
past the run and can be attached/diffed later.
Adds the --debug-print-config-path option (CommandLine.pm) and its default
of $logs_dir (TAF::Utilities::SetupVariables, right next to the existing
logs_dir default), and documents both options in taf_usage.txt and
taf_default.properties.
debug_print_config itself arrives via two different paths depending on how
it's set: --debug-print-config lands in $ctx->{flags} (via CommandLine.pm),
while the taf.debug_print_config property lands in $ctx->{options} (via
TAF::Properties) -- PrintTafConfigToFile() checks both so either entry
point works, matching what taf_usage.txt documents.
Verified functionally in an isolated podman container: running with
--debug-print-config produces the dump file at the expected path with the
expected filename format, and secret-shaped keys (db_root_pass, etc.) are
redacted.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Fully-commented, stock-MySQL-8.0-defaults reference config mirroring mariadb_default.cnf and postgresql_default.conf's role: a documented baseline showing what every other mysql_*.cnf profile (mysql_cache.cnf, mysql_simple_2gbp.cnf, ...) tunes relative to a stock server. Contributes no active settings itself. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…_dir TAF derives sysbench's --pgsql-host from dirname(db_socket), and Utilities.pm defaults db_socket to "<db_runtime_dir>/db.sock" — a directory distinct from tmp_dir. postgres.pm's unix_socket_directories was being set from tmp_dir alone, so the server listened on a socket path sysbench never looked for, and every real benchmark against PostgreSQL failed with "No such file or directory". Mirrors the runtime_dir/tmp_dir fallback mariadb.pm already used. Also corrects test_cmake_args_contains_pgsql, which asserted -DWITH_PGSQL=on against a static properties file — the flag is actually injected dynamically by ClientCmakeBuild.pm based on db_driver, so the properties file never contained it and the test was checking the wrong place. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…creds
Two bugs in hammerdb-tprocc.pm and hammerdb-tproch.pm's TCL config
generation:
- Both emitted "dbset db postgres" in the generated HammerDB config.
HammerDB itself only recognizes the prefix "pg" for PostgreSQL (see
client_source/hammerdb/HammerDB-6.0/config/database.xml), so
"postgres" was an unknown prefix — HammerDB silently fell back to
its default Oracle profile and died on a missing ORACLE_HOME. Fixed
by translating only at the TCL-emission sites (tprocc: the dbset db
line only; tproch: a local remap right after $db_type is read, since
every diset key in that function is built from it) while leaving the
internal 'postgres' value used everywhere else (hash keys, dispatch
tables, eq checks) untouched.
- Neither wrote pg_superuser/pg_superuserpass (tprocc) or
pg_tpch_superuser/pg_tpch_superuserpass (tproch) into the generated
config, so HammerDB's schema-build Monitor VU fell back to its own
built-in defaults ("postgres"/"postgres") instead of TAF's actually
configured root password, and failed authentication during
buildschema/deleteschema.
Also fixes properties/postgresql/hammerdb_tprocc_pgsql.properties,
which used property keys hammerdb-tprocc.pm never reads
(hammerdb_tprocc.warehouses/def_threads/def_duration/rampup) instead
of the real ones (hammerdb_tprocc.number_of_warehouses, global
taf.threads/taf.duration/taf.warmup_duration) — those lines were
silent no-ops that fell back to defaults. Adds the equivalent
properties/postgresql/hammerdb_tproch_pgsql.properties, which didn't
exist before despite pg_tproch_* Tcl scripts already being vendored.
Bumps hammerdb_tprocc.agent/hammerdb_tproch.agent from the stale
HammerDB-5.0 path to HammerDB-6.0, matching client_executable.
New regression coverage in tests/test_taf_postgresql.py:
- L8: end-to-end HammerDB TPC-C run against PostgreSQL.
- L9: end-to-end HammerDB TPROC-H run against PostgreSQL (previously
had no test at all, and never worked given the bugs above).
- L1 static guards: agent/client_executable version match, real
property keys in the pgsql properties files, and that
hammerdb-tproch.pm actually has postgres-specific wiring.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…as root
_db_prepare_data_dir() recursively chowned tmp_dir to the 'mysql' OS
user (needed because mariadbd/mariadb-install-db run via _os_prefix()
as 'mysql' when TAF runs as root), but not db_runtime_dir — a separate
directory (Utilities.pm defaults db_runtime_dir to "<working>/runtime/",
distinct from tmp_dir) where the bootstrap server's socket, pidfile,
and log-error actually live.
Left root-owned, mariadbd (correctly running as 'mysql' via runuser)
could not create the runtime dir's socket file: "Can't start server:
Bind on unix socket: Permission denied" — a fatal error _wait_for_start()
never noticed, since it only polls for socket readiness and not
whether the child process is still alive, so every root-mode init hung
for the full 90-second timeout before failing.
Confirmed by hand: manually chowning both data_dir and runtime_dir to
the 'mysql' UID before running mariadb-install-db and the bootstrap
server (exactly mirroring what this fix now does automatically) let
the bootstrap server start and reach "ready for connections" — with
only tmp_dir chowned, it failed identically to the unpatched code.
The regression test that now actually exercises this path is
TestL6MariaDBRegression::test_mariadb_run_exits_cleanly, which needed
two of its own preparatory fixes bundled here to even reach mariadbd
startup:
- taf.action changed from start-db-run-tests to init-start-db-run-tests
(start-db-run-tests assumes an already-initialized data dir, which
a fresh install never has) and taf.db_config_file added (mariadb.pm
requires it; previously unset here caused an earlier, different
failure).
- test_mysql_args_used_for_mariadb's assertion widened to accept
--mysql-socket, not only --mysql-host/--mysql-port: sysbench-lua.pm
defaults to a Unix socket connection, so the TCP-only flags this
test originally checked for never appear even on a fully working run.
Also fixes the L4 sysbench build to configure with --with-mysql
--with-pgsql together (previously --without-mysql --with-pgsql):
sysbench is one binary shared by every layer in this suite, and
building it pgsql-only silently broke L6 with "invalid option:
--mysql-socket=...", since nothing else in the session rebuilds it.
Adds test_sysbench_mysql_driver_available (mirroring the existing
pgsql check) and a parametrized test_sysbench_configure_driver_matrix
that verifies `configure` succeeds and reports the right driver
support for all four --with-mysql/--with-pgsql combinations, without
paying for four full builds.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…remove already-committed ones
CMakeCache.txt/CMakeFiles/ carry absolute paths from the machine that
generated them; a leftover copy from one contributor's checkout breaks
cmake outright on anyone else's machine ("CMakeCache.txt directory ...
is different than the directory ... where CMakeCache.txt was created").
Also ignore local database_software_installs/, run state, and results/
archive/logs/ output directories so `git status` stays meaningful after
running the framework functional tests.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…reSQL installs _DetectMakerFromInstallDir() checked "percona" before "postgresql"/ "postgres" in @makers, and matched only a "/"-anchored token. Percona's PostgreSQL distribution installs to a path like "percona-postgresql-18.4-.../percona-postgresql18/", so the old code matched "percona" first (misclassifying it as a MariaDB/MySQL-family build, which then failed hunting for mysql.h/libmysqlclient) and even after reordering, the anchor never matched a maker token following a "-" instead of a "/". Reorder @makers so postgresql/postgres are checked before percona, and widen the anchor to accept "-"/"_" as token separators too. Caught by framework_functional_tests::TestL4SysbenchBuild, which builds the sysbench-lua client against a Percona-installed PostgreSQL via `taf.pl --action=build-client` and failed outright before this fix. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…t/port
Both TPROC-C and TPROC-H config writers connected to the wrong place on
any machine whose hostname doesn't happen to alias localhost:
- tprocc: pg_host used $options{host}, which is GetHostName()'s
*reporting* hostname (for archive/result naming), not a connection
target. postgres.pm's pg_hba.conf only ever allows 127.0.0.1/::1, so
this only worked by accident on hosts where the real hostname
resolves back to loopback. Hardcode pg_host to 127.0.0.1.
- tproch: the socket-connection branch emitted pg_socket + pg_host but
never emitted pg_port at all. HammerDB's PostgreSQL driver has no
unix-socket support in the first place (pg_socket is not a real
dictionary key for it), so this branch silently produced a config
with no port set, and HammerDB fell back to its own default (5432)
instead of TAF's actually configured port. Route 'pg' through the
TCP branch unconditionally so pg_host and pg_port are always both
set.
Caught by framework_functional_tests::TestL8HammerdbTprocc and
TestL9HammerdbTproch on a fresh VM whose hostname doesn't alias
localhost (both passed "by accident" on hosts where it does, masking
the bug until now).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…AF's own install/build actions
Rename: a reviewer noted "tests/" reads too much like a performance-test
directory in this repo, where test_suites/ already means benchmark
workloads. Nothing else changes in this commit besides the path.
setup_almalinux10.sh and run_tests.sh are rewritten together with this
rename to fix a deeper issue found while validating them on a genuinely
fresh, isolated machine (an internal-only libvirt VM, no public/DHCP
address, provisioned specifically so no prior TAF state or manual setup
could be hiding on it):
- setup_almalinux10.sh no longer installs PostgreSQL/MariaDB or compiles
the sysbench client itself. It now shells out to TAF's own
`perl taf.pl --db-software-install --db-software-install-packages=...`
for database installs and relies on the test suite (via
`--action=*-build-client-run-tests`) to build clients. Exercising
setup this way means setup_almalinux10.sh actually tests TAF's own
install/build commands instead of duplicating and diverging from them.
It also no longer self-heals a missing sysbench CMakeLists.txt by
git-cloning upstream akopytov/sysbench -- that check was always true
(the file it looked for never existed even in a clean checkout) so it
clobbered this repo's own custom CMake build files on every run.
- run_tests.sh detects the PostgreSQL install under
database_software_installs/ (TAF's own install location) instead of a
hardcoded path, and no longer exports LD_LIBRARY_PATH globally --
doing so poisoned the Percona-bundled python3 used to run pytest
itself ("No module named 'encodings'"). TAF's own code already sets
LD_LIBRARY_PATH internally, scoped to its own subprocess calls.
test_taf_postgresql.py: L4 (sysbench build) now drives
`taf.pl --action=build-client` instead of assuming a prebuilt binary,
and L5/L6/L7 use `--action=init-start-db-build-client-run-tests` so the
client is built by the same run instead of depending on leftover state
from a previous test.
Verified end-to-end (setup_almalinux10.sh + run_tests.sh, no manual
steps) on the clean VM: all tests pass, including L8/L9 HammerDB after
the preceding commit's pg_host/pg_port fixes.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ll history test_no_sysbench_fatal_errors scanned every *.log under results/ and archive/ unconditionally. Those directories accumulate every run this machine has ever done, not just the current session's -- running the suite a second time on the same machine (exactly the repeatability the functional tests are meant to prove) surfaced a stale FATAL line left in archive/ by an earlier, unrelated run and failed this test even though the current benchmark_result run itself was completely clean. Have the benchmark_result fixture record its start time and only consider files touched at or after it, mirroring test_results_directory_structure's and test_benchmark_result_files_contain_metrics's existing "search both results/ and archive/" pattern but scoped to this run instead of all of history. Caught by running the full suite twice in a row on the same clean VM without wiping state -- exactly the "no manual setup, repeatable" guarantee this test suite exists to prove. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
… self-skip detect_pg_install() sources .taf_pg_env (written by setup_almalinux10.sh, including TAF_MARIADB_DIR when it installed MariaDB) but is itself invoked as PG_INSTALL="$(detect_pg_install)" -- a command substitution, which runs in a subshell. TAF_PG_INSTALL_DIR survived this because it gets explicitly re-exported in the parent shell right after, but TAF_MARIADB_DIR had no equivalent re-export and was silently discarded when the subshell exited. So L6's needs_mariadb marker always saw an unset TAF_MARIADB_DIR and self-skipped, even on a machine where setup_almalinux10.sh had installed MariaDB and written it to .taf_pg_env correctly. Add detect_mariadb_dir() mirroring detect_pg_install()'s existing pattern, and explicitly export its result in the parent shell. Verified on the clean VM: L6's three tests (previously 2 skipped + 1 passed) now all pass with MariaDB actually exercised. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Replace the single, unsized mariadb/postgresql "comparable" config pair with two explicit host-size tiers (4vCPU/16GB, 16vCPU/32GB), scaling buffer pool / shared_buffers, redo log / WAL, and I/O thread counts by consistent ratios so both engines commit the same fraction of host memory and vCPU-derived I/O parallelism. comparable-configuration.md documents the sizing model, corrects innodb_redo_log_capacity (which does not exist in MariaDB 12.2.2, verified against ha_innodb.cc), and lists the external host/OS conditions still required for a fair benchmark run. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2 participants
This is the first attempt to add support for PostgreSQL to the TAF test automation framework and slightly extend the MariaDB configuration options. While it was almost completely generated by Claude and while not all the intended design decisions were known to me, feel free to propose any modifications.