On Fri, 19 Jul 2024 at 21:48, Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
>
>
>
> On 7/19/24 17:16, Jelte Fennema-Nio wrote:
> > That's been moving forward, even relatively fast imho for the
> > size/impact of that patchset. But those changes are much less
> > straight-forward than this patch. And while I hope that they can get
> > committed for PG18 this year, I'm not confident about that.
>
> I don't know. My experience is that whenever we decided to not do a
> simple improvement because a more complex patch was expected to do
> something better/smarter, we often ended up getting nothing.
>
> So maybe it'd be best to get this committed, and then if the other patch
> manages to get into PG18, we can revert this change (or rather that
> patch would do that).
Yeah, I think we're aligned on this. Because that's totally what I
meant to say, but I don't seem to have written down that conclusion
explicitly.
> Maybe it's crazy-talk, but couldn't we make the GUC settable exactly
> once? That should be doable using the GUC hooks, I think. That means
> pgbouncer would set the GUC right after opening the connection, and then
> the following attempts to set it would either error out, or silently do
> nothing?
>
> Perhaps it could even allow enabling reporting for more GUCs, but once a
> GUC is on the list, it's reported forever.
This could maybe work, I'll think a bit about it. The main downside I
see is that PgBouncer can then not act as a transparent proxy, because
it cannot reset value to the value that the client expects the GUC to
be. But in practice that doesn't matter much for this specific case
because all that happens in this case is that the client gets a few
more ParameterStatus messages that it did not want.