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
youadopt 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_activityas a user interface.
>
>> Whatever the view (existing/new), any related counters would have a valid (non-NULL) value when read off the view
iffhooks 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
progresschecker 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
valuesfrom 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