On Sun, 28 Jan 2024 at 20:01, Pavel Stehule <pavel.steh...@gmail.com> wrote: > There is another reason - compatibility with other drivers. We maintain just > libpq, but there are JDBC, Npgsql, and some native Python drivers. I didn't > checked, but maybe they expect GUC with GUC_REPORT flag.
This doesn't matter, because these drivers themselves would only stop receiving certain GUC report messages if they changed this the _pq_.report_paramers GUC. And at that point the other driver is disabling the reporting on purpose. But like I said, I'm fine with forcing the currently default GUC_REPORT GUCs to be GUC_REPORT always (maybe excluding application_name). > But now, I don't see any design without problems. Your look a little bit > fragile to me, Can you explain what still looks fragile to you about my design? Like I explained at least from a proxy perspective this is the least fragile imho, since it can reuse already existing and battle tested code. > From my perspective the situation can be better if I know so defaultly > reported GUC are fixed, and cannot be broken. Then for almost all clients > (without pgbouncer users), the CUSTOM_REPORT_GUC GUC will contain just > "role", and then the risk is minimal. Which risk are you talking about here? > But still there are problems with handling of RESET ALL - so that means I > need to do a recheck of the local state every time, when I will show a prompt > with %N - that is not nice, but probably with a short list it will not be a > problem. I'm not entirely sure what you mean here. Is this still a problem if RESET ALL is ignored for _pq_.report_parameters? If so, what problem are you talking about then? > But I can imagine a client crash, and then pgbouncer executes RESET ALL, and > at this moment I would like to reset GUC_REPORT on "role" GUC. Maybe the > introduction of a new flag for DISCARD can solve it. But again there can be a > problem for which GUC the flag GUC_REPORT should be removed, because there > are not two independent lists. I don't think this is a problem. PgBouncer wouldn't rely on RESET ALL to reset the state of _pq_.report_parameters. Before handing off the old connection to a new client, PgBouncer would simply change the _pq_.report_parameters GUC back to its default value by sending a ParameterSet message. i.e. PgBouncer would use the same logic as it currently uses to correctly reset tracked GUCs (application_name, client_encoding, etc).
