| From: | "Euler Taveira" <euler(at)eulerto(dot)com> |
|---|---|
| To: | "Shaik Mohammad Mujeeb" <mujeeb(dot)sk(at)zohocorp(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | mujeebskdev <mujeeb(dot)sk(dot)dev(at)gmail(dot)com> |
| Subject: | Re: Clarification on warning when connecting to 'pgbouncer' database via Pgbouncer |
| Date: | 2025-05-27 21:22:59 |
| Message-ID: | b1040d45-983b-4a00-af24-11420a529197@app.fastmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, May 27, 2025, at 3:41 PM, Shaik Mohammad Mujeeb wrote:
> 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?
Yes. Because that comparison is for any server that psql connects to.
> Is this an expected behaviour, or would it make sense to handle Pgbouncer differently in this check?
See similar issue [1]. The error is not totally misleading. As I stated in [1],
pgbouncer is a special database. IMO it makes sense to report that some
features don't work because that's true; backslash commands don't work.
Regarding the server version, PgBouncer is a server for the client. Nothing
wrong to report it too. If you don't want to see this message use --quiet
option. In my experience, this special database is frequently used by scripts
to obtain PgBouncer statistics. These scripts generally use --quiet option
anyway. I don't think we need an extra option just to suppress this warning.
[1] https://github.com/pgbouncer/pgbouncer/issues/1143
--
Euler Taveira
EDB https://www.enterprisedb.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2025-05-27 21:27:56 | Re: PG 18 release notes draft committed |
| Previous Message | Matheus Alcantara | 2025-05-27 20:45:17 | Re: Fixing memory leaks in postgres_fdw |