Incompatibilité entre pg-bouncer et PHP/PDO avec PHP <8.4 #57

New Issue

lgourvenec · 2025-07-01T15:31:54+02:00

lgourvenec commented

2025-07-01 15:31:54 +02:00

Je cite la FAQ de pgbouncer https://www.pgbouncer.org/faq.html

How to use prepared statements with transaction pooling?

Since version 1.21.0 PgBouncer can track prepared statements in transaction pooling mode and make sure they get prepared on-the-fly on the linked server connection. To enable this feature, max_prepared_statements needs to be set to a non-zero value. See the docs for max_prepared_statements for more details.

If you use PHP/PDO, depending on its version it might be incompatible with PgBouncer its prepared statement support (#991). PHP/PDO is only compatible when PHP 8.4+ and libpq 17 are used. So for setups with older versions it’s recommended to upgrade, or to to disable prepared statements on the client side.

Disabling prepared statements in PHP/PDO

To disable use of server-side prepared statements, the PDO attribute PDO::ATTR_EMULATE_PREPARES must be set to true. Either at connect-time:

$db = new PDO("dsn", "user", "pass", array(PDO::ATTR_EMULATE_PREPARES => true));

or later:

$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);

Actuellement, nous rencontrons un problème similaire à celui décrit ici : https://github.com/pgbouncer/pgbouncer/issues/991

prepared statement "pdo_stmt_00000001" does not exist

ces erreurs arrivent de temps en temps, nous n'en connaissons pas l'origine pour sûr même si elles semblent lié à la perte d'un nœud k8s.

Serait-il possible d'upgrade hydra-sql en php8.4 (+ libpq >= 17) ? Ou bien d'ajouter l'attibut ATTR_EMULATE_PREPARES aux requêtes PDO ?

Je cite la FAQ de pgbouncer https://www.pgbouncer.org/faq.html > How to use prepared statements with transaction pooling? > > Since version 1.21.0 PgBouncer can track prepared statements in transaction pooling mode and make sure they get prepared on-the-fly on the linked server connection. To enable this feature, max_prepared_statements needs to be set to a non-zero value. See the docs for max_prepared_statements for more details. > > If you use PHP/PDO, depending on its version it might be incompatible with PgBouncer its prepared statement support (#991). PHP/PDO is only compatible when PHP 8.4+ and libpq 17 are used. So for setups with older versions it’s recommended to upgrade, or to to disable prepared statements on the client side. > Disabling prepared statements in PHP/PDO > > To disable use of server-side prepared statements, the PDO attribute PDO::ATTR_EMULATE_PREPARES must be set to true. Either at connect-time: > > $db = new PDO("dsn", "user", "pass", array(PDO::ATTR_EMULATE_PREPARES => true)); > > or later: > > $db->setAttribute(PDO::ATTR_EMULATE_PREPARES, true); Actuellement, nous rencontrons un problème similaire à celui décrit ici : https://github.com/pgbouncer/pgbouncer/issues/991 > prepared statement "pdo_stmt_00000001" does not exist ces erreurs arrivent de temps en temps, nous n'en connaissons pas l'origine pour sûr même si elles semblent lié à la perte d'un nœud k8s. Serait-il possible d'upgrade hydra-sql en php8.4 (+ libpq >= 17) ? Ou bien d'ajouter l'attibut ATTR_EMULATE_PREPARES aux requêtes PDO ?

gdupont commented

2025-07-01 15:40:24 +02:00

Je serais d'avis de monter les versions de PHP et Symfony puisque ça devrait être plutôt simple, je checkerai si on a des dépréciations ou pas pour préparer la monter vers Symfony 6.0 voire plus si c'est possible.

gdupont referenced this issue from a commit

2025-07-09 16:47:46 +02:00

chore(php) #57 : bump PHP version to 8.4

gdupont referenced this issue from a commit

2025-07-09 16:47:46 +02:00

chore(symfony) #57 : bump symfony to version 6.4 and fix deprecations

gdupont referenced this issue from a commit

2025-07-10 11:41:12 +02:00

chore(php) #57 : bump PHP version to 8.4

gdupont referenced this issue from a commit

2025-07-10 11:41:13 +02:00

chore(symfony) #57 : bump symfony to version 6.4 and fix deprecations