Clarification on warning when connecting to 'pgbouncer' database via Pgbouncer

From: Shaik Mohammad Mujeeb <mujeeb(dot)sk(at)zohocorp(dot)com>
To: "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Cc: "mujeebskdev" <mujeeb(dot)sk(dot)dev(at)gmail(dot)com>
Subject: Clarification on warning when connecting to 'pgbouncer' database via Pgbouncer
Date: 2025-05-27 18:41:03
Message-ID: 197130c5104.8a07151121912.5674016481882768643@zohocorp.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Hackers,

I was hoping to get some clarification regarding a behaviour I observed while connecting to the special 'pgbouncer' database used for administering or monitoring Pgbouncer.

After the commit cf0cab868a, introduced in PG15, I noticed that when connecting to the 'pgbouncer' database via Pgbouncer, the following warning is shown:

psql (17.2, server 1.20.1/bouncer)

WARNING: psql major version 17, server major version 1.20.

         Some psql features might not work.

From what I understand, this seems to be due to the lower version check in the connection_warnings() function, where we check if pset.sversion < 90200.

if (pset.sversion / 100 > client_ver / 100 ||

pset.sversion < 90200)

printf(_("WARNING: %s major version %s, server major version %s.\n"

"         Some psql features might not work.\n"),

   pset.progname,

   formatPGVersionNumber(client_ver, false,

cverbuf, sizeof(cverbuf)),

   formatPGVersionNumber(pset.sversion, false,

sverbuf, sizeof(sverbuf)));

In my case, pset.sversion ends up being 12001 (due to PgBouncer v1.20.1), and since that’s less than 90200, the warning gets triggered, which feels misleading. But I was wondering - does it really make sense to compare PgBouncer’s version in this context using the same logic as PostgreSQL server versions?

Is this an expected behaviour, or would it make sense to handle Pgbouncer differently in this check?

Appreciate any insights!

Thanks & Regards,
Shaik Mohammad Mujeeb
Member Technical Staff
Zoho Corp

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-05-27 18:43:14 Re: Non-reproducible AIO failure
Previous Message Tom Lane 2025-05-27 18:38:19 Tightening DecodeNumberField's parsing rules