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(dot)rouhaud(at)dalibo(dot)com <mailto:julien(dot)rouhaud(at)dalibo(dot)com>> wrote:
>>
>> On 04/06/2015 22:10, Guillaume Lelarge wrote:
>> > 2015-01-05 17:44 GMT+01:00 Guillaume Lelarge <guillaume(at)lelarge(dot)info
> <mailto:guillaume(at)lelarge(dot)info>
>> > <mailto:guillaume(at)lelarge(dot)info <mailto:guillaume(at)lelarge(dot)info>>>:
>> >
>> > 2015-01-05 17:40 GMT+01:00 Robert Haas <robertmhaas(at)gmail(dot)com
> <mailto:robertmhaas(at)gmail(dot)com>
>> > <mailto:robertmhaas(at)gmail(dot)com <mailto:robertmhaas(at)gmail(dot)com>>>:
>> >
>> > On Wed, Dec 31, 2014 at 12:46 PM, Tom Lane
> <tgl(at)sss(dot)pgh(dot)pa(dot)us <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>
>> > <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)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