po 29. 1. 2024 v 10:26 odesÃlatel Pavel Stehule <pavel.steh...@gmail.com> napsal:
> > > ne 28. 1. 2024 v 22:52 odesÃlatel Jelte Fennema-Nio <postg...@jeltef.nl> > napsal: > >> 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). >> > > ok > > >> >> > 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. >> > > because there is not 100% isolation of different layers, there is one > resource that can be modified by network layer (proxy) and by application > layer (psql). Unfortunately, I don't see any better solution, how these > layes separated. > > > >> >> > 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? >> > > The risk of not wanted reporting. I'll return to my psql prompt case. Who > will disable reporting of "rule", when psql crashes? pgbouncer will call > DISCARD ALL before reuse connection, but it ignores > _pq_.report_parameters/';.>" > > > >> >> > 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). >> > > ok, this can work, and this is the reply to my previous query. > I marked my patch as withdrawn. I'll resend it when your patch _pq_.report_parameters will be committed. Regards Pavel > > Regards > > Pavel >
