On 11.09.23 13:59, Jelte Fennema wrote:
> @Tom and @Robert, since you originally suggested extending the
> protocol for this, I think some input from you on the protocol design
> would be quite helpful. BTW, this protocol extension is the main
> reason I personally care for this patch, because it would allow
> PgBouncer to ask for updates on certain GUCs so that it can preserve
> session level SET commands even in transaction pooling mode.
> Right now PgBouncer can only do this for a handful of GUCs, but
> there's quite a few others that are useful for PgBouncer to preserve
> by default:
> - search_path
> - statement_timeout
> - lock_timeout
ISTM that for a purpose like pgbouncer, it would be simpler to add a new
GUC "report these variables" and send that in the startup message? That
might not help with the psql use case, but it would be much simpler.
Introducing this GUC, mainly when the usage will be limited to connection string, makes sense to me. Unfortunately for usage in psql it is not practical.
* For secure usage this GUC should be session immutable - probably you don't want to disable reporting for search_path, ... inside session
* Enhancing list requires more work - reading current state, parsing (theoretically the GUC "report these variables" can be marked as GUC_REPORT, so I can see this value on client side, but still there is parsing. I can imagine enhancing the SET command to style SET GUC += value or SET GUC -= value
* SET statement is transactional - that means it cannot be used when a transaction is broken, but it can be solved by some protocol based command for setting GUC without dependency on state of transaction (if it is possible, my functions changes just flag of some existing GUC, so there is not necessary memory allocation, changing the value can be different story).
I can imagine both access - special GUC allowed only in connection string - that can work as protection against unwanted remove of GUC_REPORT too, and dedicated functions for enabling, disabling GUC_REPORT. It can very nicely work together. Then we don't need any other changes. There is no necessity for protocol SET, there is no necessity for more user friendly work with lists in SET statements. And with connect settings for reporting, proxies can easily detect and get the values of GUC.
Regards
Pavel