Pldebugger

[cvas71]

Will it be possible to make it compatible with the pldebbuger debugger? If the library plprofiler.co extension is in shared_preload_libraries then the debugger does not work.

[luss]

Hmmm. I never noticed this. Hopefully jan gets a chance to try and figure this conflict out. These two extensions are complimentary

On Fri, Sep 30, 2022 at 1:57 AM Constantine Grischenko < @.***> wrote:

Will it be possible to make it compatible with the pldebbuger debugger? If the library plprofiler.co extension is in shared_preload_libraries then the debugger does not work.

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

[wieck]

This most likely depends on the load order of the two shared libraries. If you load the pldebugger later in shared_preload_libraries then the plprofiler will most likely no longer support global profiling.

The problem here is the way these PL-executor hooks are installed. Regular extension callbacks are installed one by one and supposed to remember a previous callback, then call that in a chain. PL-executor callbacks are installed as a structure where individual callback entries can be NULL (and are in both extensions). Neither pldebugger nor plprofiler make any attempt to call the any other PLpgSQL_plugin in a chain. If both plugins get loaded, only the last will have its hooks being called.

I can try to make it so that the plprofiler defines all callbacks and if a previous plugin was installed, perform chain calls. However, this needs to be tested against all versions of PostgreSQL that we intend to support because the number of callback functions in the PLpgSQL_plugin structure has increased over time.

[cvas71]

It would be great if you can do it.

[wieck]

I will not do it right now. At this moment I am focusing on getting plprofiler 4.2 released so that I can work with Devrim Gündüz on including it in the PGDG RPM repository. I hope the RPMs can be done before PGConf.EU in Berlin. I can work on this after I am back from Germany in November.

I also hope to meet Dave Page in Berlin to discuss if/how we could integrate the plprofiler into pgadmin. I believe pgadmin is implemented in Python. The plprofiler command line utility is actually a wrapper around a Python class using psycopg2. So that should integrate nicely.

[cvas71]

The problem manifests itself even if the library is not specified in shared_preload_libraries. Just install the extension. Execute in session SELECT pl_profiler_reset_local(); after that, it will no longer be possible to debug in this session. Only reinstallation of connection with a DB helps.

[wieck]

Execute in session SELECT pl_profiler_reset_local(); after that, it will no longer be possible to debug in this session.

Yes, that is to be expected. The above call does install the plpgsql_plugin instrumentation and thereby overrides the pldebugger.

[cvas71]

Is it possible to make it possible to turn profiling on and off as needed, as it is in PL/SQL Oracle?

[wieck]

On 10/10/22 02:44, Constantine Grischenko wrote:

Is it possible to make it possible to turn profiling on and off as needed, as it is in PL/SQL Oracle?

I am not clear what you are asking for here. The profiler can be enabled and disabled using the Python command line utility either globally or for a specific backend PID. Or it can be enabled within a session by calling the appropriate profiler functions. However, in the latter case the profiling data is only accessible from inside that session, not from the outside.

How exactly do you envision the profiling being enabled/disabled in addition to the above?

Regards, Jan

[cvas71]

Maybe I didn't find what I need. To be able to enable/disable profiling in the current session.

[luss]

Seems an enhancement request for after 4.2 release

On Fri, Sep 30, 2022 at 10:39 AM Jan Wieck @.***> wrote:

This most likely depends on the load order of the two shared libraries. If you load the pldebugger later in shared_preload_libraries then the plprofiler will most likely no longer support global profiling.

The problem here is the way these PL-executor hooks are installed. Regular extension callbacks are installed one by one and supposed to remember a previous callback, then call that in a chain. PL-executor callbacks are installed as a structure where individual callback entries can be NULL (and are in both extensions). Neither pldebugger nor plprofiler make any attempt to call the any other PLpgSQL_plugin in a chain. If both plugins get loaded, only the last will have its hooks being called.

I can try to make it so that the plprofiler defines all callbacks and if a previous plugin was installed, perform chain calls. However, this needs to be tested against all versions of PostgreSQL that we intend to support because the number of callback functions in the PLpgSQL_plugin structure has increased over time.

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