[question] How to verify if profiler is running? How to disable profiling if connection is lost?

[markosutic]

Hello,

It is mentioned in the docs: "As with any database maintenance operations, this should only be done in a connection loss safe environment as losing the connection in the middle of the monitoring would leave those settings behind permanently."

In case profiling was running when connection was lost, can we verify somehow that profiling is active on the database? How can we disable profiling if connection is lost in the middle of the monitoring?

Sorry for asking duplicate question if this is already mentioned somewhere. I couldn't find this information.

Thank you for the info.

[luss]

It sounds like you want to run the profiler on a production database. It's a bad idea... Replicate your performance problem in a dev/test environment and profile there.

--Denis

On Fri, May 20, 2022 at 5:08 PM markosutic @.***> wrote:

Hello,

It is mentioned in the docs: "As with any database maintenance operations, this should only be done in a connection loss safe environment as losing the connection in the middle of the monitoring would leave those settings behind permanently."

In case profiling was running when connection was lost, can we verify somehow that profiling is active on the database? How can we disable profiling if connection is lost in the middle of the monitoring?

Sorry for asking duplicate question if this is already mentioned somewhere. I couldn't find this information.

Thank you for the info.

— Reply to this email directly, view it on GitHub https://github.com/bigsql/plprofiler/issues/10, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMWOHWD4DM2IHLJHC46IQTVK75LXANCNFSM5WQSZGFA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[markosutic]

Thank you @luss for the advice, I am aware that running profiler on the live production is not recommended and should be avoided.

But still, is it possible to disable global profiling if connection is lost? Maybe running ALTER SYSTEM and pg_reload_conf() manually?

Or can I check somehow that profilling is enabled and that diagnostic info is being collected?

Thanks

[luss]

Jan would have to answer your specific question. I can mostly only pontificate. ;-)

On Sat, May 21, 2022 at 4:05 AM markosutic @.***> wrote:

Thank you @luss https://github.com/luss for the advice, I am aware that running profiler on the live production is not recommended and should be avoided.

But still, is it possible to disable global profiling if connection is lost? Maybe running ALTER SYSTEM and pg_reload_conf() manually?

Or can I check somehow that profilling is enabled and that diagnostic info is being collected?

Thanks

— Reply to this email directly, view it on GitHub https://github.com/bigsql/plprofiler/issues/10#issuecomment-1133560836, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMWOHULWRGCKKCPIBBMPDLVLCKK3ANCNFSM5WQSZGFA . You are receiving this because you were mentioned.Message ID: @.***>

[wieck]

On 5/21/22 11:02, Denis Lussier wrote:

Jan would have to answer your specific question. I can mostly only pontificate. ;-)

plprofiler no longer uses settings in GUCs to control global collection. Instead it is a shared memory flag that causes collection at transaction end.

The flag is set and cleared with the function

 pl_profiler_set_enabled_global(bool)

The flag is not automatically cleared if the connection that set it disconnects. As Denis said, none of this is supposed to be used in production. But you can disable collection by calling that function.

Best Regards, Jan

On Sat, May 21, 2022 at 4:05 AM markosutic @.***> wrote:

Thank you @luss https://github.com/luss for the advice, I am aware that running profiler on the live production is not recommended and should be avoided.

But still, is it possible to disable global profiling if connection is lost? Maybe running ALTER SYSTEM and pg_reload_conf() manually?

Or can I check somehow that profilling is enabled and that diagnostic info is being collected?

Thanks

— Reply to this email directly, view it on GitHub https://github.com/bigsql/plprofiler/issues/10#issuecomment-1133560836, or unsubscribe

https://github.com/notifications/unsubscribe-auth/AAMWOHULWRGCKKCPIBBMPDLVLCKK3ANCNFSM5WQSZGFA . You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/bigsql/plprofiler/issues/10#issuecomment-1133648524, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACYRMUMO6KXJMFSSSA6MADVLD3IHANCNFSM5WQSZGFA. You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Jan Wieck

[markosutic]

@wieck thank you very much for the info.

Best regards, Marko

[markosutic]

@wieck, sorry, one more question. Using Global Profiling is risky and it should be avoided on the production system due to noted reasons.

Is session-level local profiling safe enough to be used on the production system?

[wieck]

On 5/23/22 05:26, markosutic wrote:

@wieck https://github.com/wieck, sorry, one more question. Using /Global Profiling/ is risky and it should be avoided on the production system due to noted reasons.

Is session-level local profiling safe enough to be used on the production system?

The reason for discouraging usage of the profiler in production is that this code is far less reviewed and tested against all the different versions of PostgreSQL than PostgreSQL itself. Therefore the risk of encountering a bug is higher. Every extension that implements functions in C has that risk. Using the profiler global or local makes little difference.

Best Regards, Jan

[markosutic]

Thank you Jan for the info.

[luss]

Hey Jan, I added you back as a committer to bigsql/plprofiler. I will drop the pgsql-io/plprofiler project.

On Mon, May 23, 2022 at 4:20 PM markosutic @.***> wrote:

Thank you Jan for the info.

— Reply to this email directly, view it on GitHub https://github.com/bigsql/plprofiler/issues/10#issuecomment-1135101320, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMWOHVBJNHFHPBYWQM3NEDVLPSBJANCNFSM5WQSZGFA . You are receiving this because you were mentioned.Message ID: @.***>

[luss]

Seems a lot of things are getting done. Let me know when a release is tagged and i'll do some independent testing.

On Thu, Jun 2, 2022 at 5:26 PM Jan Wieck @.***> wrote:

Closed #10 https://github.com/bigsql/plprofiler/issues/10 as completed.

— Reply to this email directly, view it on GitHub https://github.com/bigsql/plprofiler/issues/10#event-6731752623, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMWOHQJCXHRYPX3BLNJQS3VNERJXANCNFSM5WQSZGFA . You are receiving this because you were mentioned.Message ID: @.***>

[wieck]

On 10/11/22 04:41, Denis Lussier wrote:

Seems a lot of things are getting done. Let me know when a release is tagged and i'll do some independent testing.

The release 4.2 was tagged on October 4th. The corresponding PyPI client module was uploaded that same day. I opened a case to add the packages to the pgrpms repository (driving the PGDG build farm) on October 5th, but have not heard back from Devrim yet. I will follow on that shortly.

https://github.com/bigsql/plprofiler/tags https://pypi.org/project/plprofiler-client/#history https://redmine.postgresql.org/issues/7725

On Thu, Jun 2, 2022 at 5:26 PM Jan Wieck @.***> wrote:

Closed #10 https://github.com/bigsql/plprofiler/issues/10 as completed.

— Reply to this email directly, view it on GitHub https://github.com/bigsql/plprofiler/issues/10#event-6731752623, or unsubscribe

https://github.com/notifications/unsubscribe-auth/AAMWOHQJCXHRYPX3BLNJQS3VNERJXANCNFSM5WQSZGFA . You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/bigsql/plprofiler/issues/10#issuecomment-1274321897, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACYRMWIJWIH65UTKVZLR4LWCUR5DANCNFSM5WQSZGFA. You are receiving this because you modified the open/close state.Message ID: @.***>