[RNDSTROPPY-114]: ydb postgres compatible tpcc

[Cianidos]

Description of Changes

Add TPC-C workload support for YDB via its experimental PostgreSQL-compatible wire
protocol (pgwire). This enables benchmarking YDB using the standard postgres driver
(pgx) instead of the native gRPC SDK, testing real-world pgwire compatibility.

Files changed:

• workloads/tpcc/ydb_pgwire.sql — new SQL dialect: PostgreSQL-typed schema without
  CASCADE, REFERENCES, FOR UPDATE, stored procedures, or RETURNING clauses
• workloads/tpcc/tx.ts — HAS_RETURNING ENV override (pgwire portals don't support
  UPDATE...RETURNING, so this flag splits it into separate UPDATE + SELECT)

YDB pgwire compatibility report

Tested against ghcr.io/ydb-platform/local-ydb:nightly with YDB_EXPERIMENTAL_PG=1
on 2026-04-10.

Supported

DDL (CREATE/DROP TABLE), single-statement DML, simple-protocol SELECTs, read-only
transactions (stock_level, order_status), data querying after loading via native gRPC.

Degraded — workaround available, full spec achievable

Issue	Workaround
No TLS	sslmode=disable in connection URL
Extended query protocol broken (Portal "" not found)	default_query_exec_mode=simple_protocol in URL
No COPY protocol	plain_bulk insert method (~10x slower than native)
Parameter limit on wide tables	bulkSize=20 (customer: 21 cols × 500 = 10500 params overflows)
No CASCADE in DROP TABLE	Individual DROP TABLE IF EXISTS per table
No REFERENCES (FK constraints)	Omit from schema
No stored procedures	tx.ts transaction path only
UPDATE...RETURNING fails (Portal "" not found)	-e HAS_RETURNING=false → separate UPDATE + SELECT
FOR UPDATE silently ignored (warning 7000)	Removed from SQL
Auth lockout (4 failed attempts → 1h ban)	pgx TLS-probe storm triggers it; fix via --auth-config-path with attempt_threshold: 0

Limited — functional with restrictions, not production-grade

• Bulk loading via pgwire is ~10x slower than native gRPC (100k items: ~5 min vs ~25 s).
  Recommended: load via native driver, query via pgwire.
• POOL_SIZE=1 mandatory to avoid auth lockout storms from parallel connection TLS probes.

Blocking — TPC-C cannot run full-spec via pgwire

Multi-statement write transactions break: after BEGIN + SELECT, the subsequent
UPDATE/INSERT returns Transaction not found (code 2015). This causes ~90% error
rate on new_order and payment transactions. Read-only transactions and single-statement
delivery work correctly. This appears to be a YDB pgwire transaction-handling bug —
until resolved, only read-heavy workloads are viable over pgwire.

How Has This Been Tested?

# 1. Load data via native YDB gRPC driver (~5 min, scale factor 1)
K6_SETUP_TIMEOUT=10m ./build/stroppy run tpcc/tx -d ydb --no-steps workload

# 2. Run TPC-C workload via pgwire (read-only txs succeed, write txs hit blocker)
./build/stroppy run tpcc/tx tpcc/ydb_pgwire -d pg \
  -D url='postgres://root:1234@localhost:5433/local?sslmode=disable&default_query_exec_mode=simple_protocol' \
  -D defaultInsertMethod=plain_bulk -D bulkSize=20 \
  -e POOL_SIZE=1 -e TX_ISOLATION=serializable -e HAS_RETURNING=false \
  --steps workload -- --iterations 1000

Result: 1000 iterations, all 5 tx types dispatched, read-only txs (stock_level,
order_status) commit successfully, write txs (new_order, payment) fail with
"Transaction not found". 5.8% overall commit rate, 90% error rate.

Type of Changes

• New feature
• Documentation improvement

Checklist

• I have read the CONTRIBUTING.md
• I have checked build and tests
• I have updated documentation if needed

feat(tpcc): ydb-pg wire support attempt

Closes RNDSTROPPY-114