IgorOhrimenko

[package]
name = "setconfig-gate-bench"
version = "0.1.0"
edition = "2021"

[dependencies]
regex = "1"
once_cell = "1"

IgorOhrimenko

PgDog: a RESET inside a transaction leaves poisoned connections in the pool

When a client runs RESET <param>, PgDog clears its record of the server's tracked parameters, assuming the session is back to its defaults and will be re-synced on the next checkout (backend/server.rs, CommandComplete handling: "RESET" => self.client_params.clear()).

That assumption breaks inside a transaction. A ROLLBACK undoes the RESET, reviving the parameter values that were in effect before it — but PgDog has just stopped tracking them. The connection returns to the pool carrying session state the

IgorOhrimenko

PgDog: parameterized set_config() bypasses interception and poisons pooled connections

SELECT pg_catalog.set_config('search_path', '', false) sent as a literal is correctly intercepted by the query parser (#1055 / #1072) and tracked as session state.

However, the same call sent over the extended protocol with bound parameters:

SELECT pg_catalog.set_config($1, $2, false)
-- Bind: $1 = 'search_path', $2 = ''

IgorOhrimenko

#!/usr/bin/env bash
# Deterministic reproduction for https://github.com/cloudnative-pg/cloudnative-pg/issues/9770
# "Postgres image update stalls when plugin-barman-cloud is installed"
#
# The stall needs a kubelet affected by https://github.com/kubernetes/kubernetes/issues/137146
# (a 1.35.0-1.35.3 regression): after a kubelet restart, a pod's main container that has a
# restartable init container (the plugin sidecar) and a startup probe is never restarted
# once it exits. CNPG instance pods with plugin sidecars match this exactly.
#
# Sequence: healthy 2-instance cluster -> restart the kubelet (arms the trap for every pod

IgorOhrimenko

PgDog: prepared statements cache retains gigabytes after clients disconnect

Reproduces a memory retention issue in PgDog's global prepared statements cache (observed on v0.1.50, mechanism present on main).

Mechanism

Long-lived clients that keep preparing unique SQL statements (report jobs, ORMs interpolating values into SQL, cron batches) grow the global cache (frontend/prepared_statements/global_cache.rs) to millions of entries. Entries

IgorOhrimenko

PgDog AST query-cache memory balloon

Reproduces a memory balloon in PgDog caused by the AST query cache (query_cache_limit, default 1000), not by prepared statements and not by allocator retention.

The mechanism

PgDog keeps one global LRU cache of parsed query ASTs per process (static CACHE, shared across all clients and all databases the instance

IgorOhrimenko

PgDog memory balloon: unbounded prepared-statement cache (in-use statements are never capped)

A client that opens many distinct server-side prepared statements over the extended protocol and keeps them open makes PgDog's prepared-statement cache grow to gigabytes.

Key points:

• prepared_statements_limit does not bound this. It only controls eviction of unused statements (per-server-connection LRU, which protects the backend Postgres). In-use statements (still referenced by a connected client, used > 0) are never evicted, so the pgdog-side

IgorOhrimenko

dragonfly-operator: spec.additionalVolumeMounts usage patterns

spec.additionalVolumeMounts mounts extra volumes into the Dragonfly main container. It is the missing counterpart to the existing spec.additionalVolumes (which only adds volumes to the pod, without mounting them). Pairing the two lets you compose several snapshot/cache patterns without any snapshot-specific API — the operator does not need to know what the volume is for.

Status: additionalVolumeMounts is proposed in a fork of dragonfly-operator (based on v1.6.1). additionalVolumes, initContainers and spec.snapshot.dir

IgorOhrimenko

# PgDog RSS-retention reproduction stand (Kubernetes).
# See pgdogdev/pgdog issue: RSS not returned to OS after bursts of large messages.
#
#   kubectl apply -f pgdog-rss-repro-stand.yaml
#   # generate a ~3MB client-message load file inside the loadgen pod:
#   POD=$(kubectl -n pgdog-lt get pod -l app=loadgen -o name)
#   kubectl -n pgdog-lt exec $POD -- sh -c \
#     'printf "SELECT octet_length('\''%s'\'');\n" "$(head -c 3000000 /dev/zero | tr "\0" a)" > /tmp/bigq.sql'
#   # drive 500 clients for 80s against the DEFAULT pgdog (balloons and sticks):
#   kubectl -n pgdog-lt exec $POD -- env PGPASSWORD=ltpass pgbench -n -c 500 -j 16 -T 80 \

IgorOhrimenko

#!/bin/bash
# Cleanup: delete kind cluster
kind delete cluster --name cnpg-bug
echo "Cluster deleted."