Re: remote query debugging was: Plugins redux
От | Tom Lane |
---|---|
Тема | Re: remote query debugging was: Plugins redux |
Дата | |
Msg-id | 28808.1155153889@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | remote query debugging was: Plugins redux (Andreas Pflug <pgadmin@pse-consulting.de>) |
Ответы |
Re: remote query debugging was: Plugins redux
|
Список | pgsql-hackers |
Andreas Pflug <pgadmin@pse-consulting.de> 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
В списке pgsql-hackers по дате отправления: