0

I've noticed since upgrading from pgBouncer 1.17 to 1.18 (but not otherwise changing my configuration) that canceled queries result in a fatal error that crashes the service, i.e.

2023-02-23 03:29:32.097 UTC [27246] LOG started sending cancel request
2023-02-23 03:29:32.098 UTC [27246] FATAL @src/server.c:583 in function server_proto(): server_proto: server in bad state: 14

I can recreate this by connecting to pgBouncer via psql, running a long query, and issuing a cancellation request.

My pgbouncer.ini file is below. There haven't been any changes to it between the upgrade from 1.17 to 1.18.

[databases]
%include /etc/pgbouncer/hosts.ini

[users]

[pgbouncer]
syslog = 1
ignore_startup_parameters = extra_float_digits ssl_renegotiation_limit
logfile = /var/log/postgresql/pgbouncer.log
pidfile = /var/run/postgresql/pgbouncer.pid
listen_addr = *
listen_port = 6432
unix_socket_dir = /var/run/postgresql
client_tls_sslmode=allow
client_tls_key_file =  /etc/letsencrypt/live/x/privkey.pem
client_tls_cert_file =  /etc/letsencrypt/live/x/fullchain.pem
server_tls_sslmode = verify-ca
server_tls_ca_file = /etc/azure.postgresql.pem
auth_type = plain
auth_file = /etc/pgbouncer/userlist.txt
admin_users = swpgbouncer
pool_mode = transaction
max_client_conn = 995
default_pool_size = 20

I can't find anything in the 1.18 changelog that would cause this -- is there something else I'm missing?

Update Here is some additional info:

  • pgBouncer 1.18 is running on an Ubuntu 18.04.6 LTS virtual machine
  • Postgres is version 11 on an Azure Database for PostgreSQL single server
dumbchemistry
  • 384
  • 1
  • 5
  • 21
  • I can't reproduce this using a simple config in 1.18.0. Can you still get this if you simplify your configuration? (get rid of the ssl stuff, get rid of the %include stuff) – jjanes Feb 23 '23 at 18:03
  • Thanks for the suggestion. The issue seems to persist if I put a single database under `[databases]` and if I turn off SSL and remove the options, and try various other combinations. Also, I just updated the original question with some version info. – dumbchemistry Feb 23 '23 at 18:52
  • I still can't reproduce it with those versions. Can you point pgbouncer to a non-Azure database to see if that replicates? Out of curiosity, why such an new pgbouncer with such an old ubuntu and PostgreSQL? And what is the line under [databases] (or in /etc/pgbouncer/hosts.ini) which you are using? How did you install? – jjanes Feb 23 '23 at 19:41
  • Unfortunately, I don't have a good reason regarding the versions -- we plan on migrating to Postgres 15 and Azure Database for PostgreSQL Flexible Server soon. pgBouncer was installed via apt-get. The line under `[databases]` was `* = host=xxx-sandbox6-001.postgres.database.azure.com port=5432`. I can't try a non-Azure database right now, but I will give it a shot and update the question. I will also try it on a fresh VM. For now I will likely restore an older version of the VM with pgBouncer 1.17, though my curiosity remains. – dumbchemistry Feb 23 '23 at 20:44

0 Answers0