Re: Publish autovacuum informations

On 29/02/2016 20:20, Fabrízio de Royes Mello wrote:
>
> On Mon, Feb 29, 2016 at 3:04 PM, Julien Rouhaud
> <julien.rouhaud@dalibo.com <mailto:julien.rouhaud@dalibo.com>> wrote:
>>
>> On 04/06/2015 22:10, Guillaume Lelarge wrote:
>> > 2015-01-05 17:44 GMT+01:00 Guillaume Lelarge <guillaume@lelarge.info
> <mailto:guillaume@lelarge.info>
>> > <mailto:guillaume@lelarge.info <mailto:guillaume@lelarge.info>>>:
>> >
>> >     2015-01-05 17:40 GMT+01:00 Robert Haas <robertmhaas@gmail.com
> <mailto:robertmhaas@gmail.com>
>> >     <mailto:robertmhaas@gmail.com <mailto:robertmhaas@gmail.com>>>:
>> >
>> >         On Wed, Dec 31, 2014 at 12:46 PM, Tom Lane
> <tgl@sss.pgh.pa.us <mailto:tgl@sss.pgh.pa.us>
>> >         <mailto:tgl@sss.pgh.pa.us <mailto:tgl@sss.pgh.pa.us>>> wrote:
>> >         > I'd be all right with putting the data structure
> declarations in a file
>> >         > named something like autovacuum_private.h, especially if
> it carried an
>> >         > annotation that "if you depend on this, don't be surprised
> if we break
>> >         > your code in future".
>> >
>> >         Works for me.  I am not in general surprised when we do
> things that
>> >         break my code, or anyway, the code that I'm responsible for
>> >         maintaining.  But I think it makes sense to segregate this
> into a
>> >         separate header file so that we are clear that it is only
>> >         exposed for
>> >         the benefit of extension authors, not so that other things in
>> >         the core
>> >         system can touch it.
>> >
>> >
>> >     I'm fine with that too. I'll try to find some time to work on that.
>> >
>> >
>> > So I took a look at this this week. I discovered, with the help of a
>> > coworker, that I can already use the AutoVacuumShmem pointer and read
>> > the struct. Unfortunately, it doesn't give me as much details as I would
>> > have liked. The list of databases and tables aren't in shared memory.
>> > They are local to the process that uses them. Putting them in shared
>> > memory (if at all possible) would imply a much bigger patch than I was
>> > willing to write right now.
>> >
>> > Thanks anyway for the help.
>> >
>> >
>>
>> Sorry to revive such an old thread.
>>
>> I think some hooks in the autovacuum could be enough to have good
>> insight without exposing private structure.
>>
>
> Interesting idea...
>

Thanks for looking at it!

>
>> Please find attached a patch that adds some hooks to the autovacuum, and
>> as an example a quick proof of concept extension that use them and allow
>> to see what are the autovacuum worker todo list, skipped tables and so on.
>>
>> I'm not really sure about which information should be provided, so I'm
>> open to any suggestion to improve this.
>>
>
> I have a look at the patch and it's compile without warning and without
> regression.
>
> But something goes wrong when installing the extension:
>
> [...]
> /usr/bin/install -c -m 644  '/data/home/fabrizio/pgsql/share/doc/extension/'
> /usr/bin/install: missing destination file operand after
> ‘/data/home/fabrizio/pgsql/share/doc/extension/’
> Try '/usr/bin/install --help' for more information.
> make: *** [install] Error 1
>

Oups, I'm not really sure what I removed and shouldn't have. I attached
v2 of the extension with a "standard" Makefile, which I just tested and
works fine.

> Regards,
>
> --
> Fabrízio de Royes Mello
> Consultoria/Coaching PostgreSQL
>>> Timbira: http://www.timbira.com.br
>>> Blog: http://fabriziomello.github.io
>>> Linkedin: http://br.linkedin.com/in/fabriziomello
>>> Twitter: http://twitter.com/fabriziomello
>>> Github: http://github.com/fabriziomello


--
Julien Rouhaud
http://dalibo.com - http://dalibo.org