Re: [PROPOSAL] VACUUM Progress Checker.

Поиск
Список
Период
Сортировка
От Syed, Rahila
Тема Re: [PROPOSAL] VACUUM Progress Checker.
Дата
Msg-id C3C878A2070C994B9AE61077D46C3846881534FC@MAIL703.KDS.KEANE.COM
обсуждение исходный текст
Ответ на Re: [PROPOSAL] VACUUM Progress Checker.  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: [PROPOSAL] VACUUM Progress Checker.  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [PROPOSAL] VACUUM Progress Checker.  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
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 iff
hooksare 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
checkermodule 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
fromshared 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?

Thank you,
Rahila Syed




______________________________________________________________________
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: raw output from copy
Следующее
От: Tom Lane
Дата:
Сообщение: Re: drop/truncate table sucks for large values of shared buffers