Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The other, probably more controversial bit of functionality is that there
>> needs to be a way to cause a backend to load a PL plugin shared library
>> without any cooperation from the connected client application.

> A similar issue applies to plain SQL that's not touching any PL: In the
> past, I encountered numerous situations where I'd have liked to take a
> peek at the current application's queries (on MSSQL, this can be done
> with SQL Profiler), but not have constant statement logging. IMHO it
> would be a good idea if

> - debugging could be turned on and off on-the-fly, e.g. to skip the app
> startup phase. Thus I question the statement "GUC variable is sufficient"
> - the mechnism would cover plain SQL too.

I'd turn that around: I think you are arguing for a way to change GUC
settings on-the-fly for a single existing session, without cooperation
from the client.  You can do that now if you're desperate enough (change
postgresql.conf, SIGHUP just that backend, revert postgresql.conf
change) but I agree something easier would be nice.  In any case the
problem needs a generic solution not something that only works for PL
plugin loading, so solving it within GUC seems right to me.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to