Re: Application name patch - v4

On 12/1/09, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Dave Page wrote:
> > Upthread, Tom suggested a new 'SET DEFAULT ...' variant of SET which
> > could be used to set the default GUC value that RESET would revert to.
> > This seems to me to be the ideal solution, and I'd somewhat hesitantly
> > volunteer to work on it (hesitantly as it means touching the parser
> > and other areas of the code I currently have no experience of).
>
>
> If an application can do SET DEFAULT, how does the connection pooler
> *really* reset the value back to what it was?

By doing SET DEFAULT...

There actually *is* a problem that SET DEFAULT would solve:

1) Pooler creates a connection with one default value.
2) Client creates a connection with another default value (giving param
in startup pkt)
3) Pooler does SET to apply client's default values.
4) Client does SET to some random value
5) Client does RESET foo/ALL; expecting get default value from 2), instead
it gets poolers default value from 1).

The inconsistency would be fixed if pooler could do SET DEFAULT in 3).

Note - client doing SET DEFAULT itself would not break anything.
As long we are talking about protocol-tracked parameters...

OTOH, the only app that exhibits the such RESET problem is src/test/regress
so I'm not sure it's worth spending effort to fix this. Especially
as this open door on app doing SET DEFAULT on non-tracked GUC vars,
which seems to be a much bigger problem.

I don't see how this SET DEFAULT would fix the appname vs. poolers problem
in any way.

--
marko