On 2015-07-02 PM 11:00, Syed, Rahila wrote: > Hello, > >> Unless I am missing something, I guess you can still keep the actual code >> that updates counters outside the core if you adopt an approach that Simon >> suggests. > Yes. The code to extract progress information from VACUUM and storing in > shared memory can be outside core even with pg_stat_activity as a user > interface. > >> Whatever the view (existing/new), any related counters would have a valid >> (non-NULL) value when read off the view iff hooks are set perhaps because >> you have an extension that sets them. >> I guess that means any operation that "supports" progress tracking would >> have an extension with suitable hooks implemented. > Do you mean to say , any operation/application that want progress tracking > feature will dynamically load the progress checker module which will set the > hooks for progress reporting? > If yes , unless I am missing something such dynamic loading cannot happen if > we use pg_stat_activity as it gets values from shared memory. Module has to > be a shared_preload_library > to allocate a shared memory. So this will mean the module can be loaded only > at server restart. Am I missing something? >
Assuming that set of hooks per command and shared memory structure(s) is a way to go, I meant to say that hook implementations per command would be in their separate modules, of course loaded at the server start for shared memory). Of those, your proposed patch has vacuum_progress, for example. And in context of my comment above, that means the view would say NULL for commands for which the module has not been set up in advance. IOW, between showing NULL in the view and dynamically loading hook functions, we choose the former because I don't know what the latter means in postgres. Having said that, Tom's suggestion to export pgstat.c function(s) for command(s) may be a more appealing way to go. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
