On 01/03/2016 20:29, Jim Nasby wrote: > On 3/1/16 8:37 AM, Julien Rouhaud wrote: >>> > >>> >We understood (IMHO is an interesting idea) but as Michael said >>> hooks is >>> >for a general purpose. So can you demonstrate other use cases for this >>> >new hooks? >>> > >> I can think of several usage. First, since the hook will always be >> called, an extension will see all the activity a worker is doing when >> exposing private structure will always be some kind of sampling. Then, > > I think that's pretty key. If you wanted to create an extension that > logs vacuums (which would be great, since current state of the art is > logs + pgBadger), you'd want to gather your data about what the vacuum > did as the vacuum was ending. >
Indeed these information are missing. I guess that'd be possible by adding (or moving) a hook in lazy_vacuum_rel() that provide access to part or all of the LVRelStats and rusage informations. > I can certainly see cases where you don't care about that and just want > what's in shared memory, but that would only be useful for monitoring > what's happening real-time, not for knowing what final results are. > > BTW, I think as much of this as possible should also work for regular > vacuums. > You mean for database wide vacuum? >> you can have other information that wouldn't be available just by >> exposing private structure. For instance knowing a VACUUM isn't >> performed by the worker (either because another worker is already >> working on it or because it isn't needed anymore). IIRC there was a >> discussion about concurrency issue in this case. We can also know if the >> maintenance was cancelled due to lock not obtained fast enough. >> Finally, as long as the hooks aren't use, they don't have any overhead. >> I agree that all this is for monitoring purpose. >> >> I'm not sure what are the fancy things that Michael had in mind with >> exposing the private structure. Michael, was it something like having >> the ability to change some of these data through an extension? -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
