Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't send extra_float_digits for PostgreSQL 12+ by default #3432

Closed
NKame opened this issue Nov 7, 2024 · 5 comments
Closed

Don't send extra_float_digits for PostgreSQL 12+ by default #3432

NKame opened this issue Nov 7, 2024 · 5 comments

Comments

@NKame
Copy link

NKame commented Nov 7, 2024

Describe the issue
Connecting through PgBouncer with a default configuration fails.

Driver Version?
All supported.

Java Version?
All supported.

OS Version?
All supported.

PostgreSQL Version?

= 12

To Reproduce
Connect throught PgBouncer. Fails with unsupported extra_float_digits parameter.

Expected behaviour
Connected to the database.

Context
extra_float_digits has been introduced in PostgreSQL 8.4 to play around the apparent precision of the lossy datatype "float". At first to increase the precision sent to the client, then since version 12, to reduce it. In pgJDBC, if you want the "full" precision with a server 12+, you must override this parameter since it is forced in the driver to the value 3 if the server is 9+, that means you have to send it twice to the server. Furthermore, by default it's not authorized by default with PgBouncer: "the internet" answer is to change the server, whereas it doesn't make really sense to send it at all for PostgreSQL 12+. (And the question of forcing a default for the lossy datatype should be asked... in my view it should be an explicit choice from the application owner).

@jorsol
Copy link
Member

jorsol commented Nov 7, 2024

PgBouncer should be configured with ignore_startup_parameters = extra_float_digits
https://www.pgbouncer.org/config.html#ignore_startup_parameters

@NKame
Copy link
Author

NKame commented Nov 7, 2024

I address precisely this thing in the context section. But that doesn't answer the secondary main concern: why reduce arbitrary the float precision? Why should we send 2 instructions to get the native precision when none is required at all?

@jorsol
Copy link
Member

jorsol commented Nov 7, 2024

https://www.postgresql.org/docs/17/datatype-numeric.html#DATATYPE-FLOAT

Applications that wanted precise values have historically had to set extra_float_digits to 3 to obtain them. For maximum compatibility between versions, they should continue to do so.

@NKame
Copy link
Author

NKame commented Nov 7, 2024

Same link, but the information is the the same since 2019.
By default, floating point values are output in text form in their shortest precise decimal representation; the decimal value produced is closer to the true stored binary value than to any other value representable in the same binary precision.
For compatibility with output generated by older versions of PostgreSQL, and to allow the output precision to be reduced, the [extra_float_digits](https://www.postgresql.org/docs/17/runtime-config-client.html#GUC-EXTRA-FLOAT-DIGITS) parameter can be used to select rounded decimal output instead.
And reading furthermore
The meaning of this parameter, and its default value, changed in PostgreSQL 12
and even further
If the value is 1 (the default) or above, float values are output in shortest-precise format; see [Section 8.1.3](https://www.postgresql.org/docs/17/datatype-numeric.html#DATATYPE-FLOAT). The actual number of digits generated depends only on the value being output, not on the value of this parameter.

So I was wrong assuming you needed to reset it to get full precision. Since version 12 it is not needed anymore, so the breaking of PgBouncer default conf on PostgreSQL 12+ is even more meaningless.

davecramer pushed a commit that referenced this issue Nov 14, 2024

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
@ecki
Copy link
Contributor

ecki commented Jan 22, 2025

It’s fixed in #3490 #3491 now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants