Re: Publish autovacuum informations - Mailing list pgsql-hackers

From Guillaume Lelarge
Subject Re: Publish autovacuum informations
Date
Msg-id CAECtzeWUB6cRgEJQM+wf9+TzMEFYHrCzUjGjYQEwEvDNupabNg@mail.gmail.com
Whole thread Raw
In response to Re: Publish autovacuum informations  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
2014-12-29 17:03 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
Guillaume Lelarge <guillaume@lelarge.info> writes:
> All in all, I want to get informations that are typically stored in shared
> memory, handled by the autovacuum launcher and autovacuum workers. I first
> thought I could get that by writing some C functions embedded in an
> extension. But it doesn't seem to me I can access this part of the shared
> memory from a C function. If I'm wrong, I'd love to get a pointer on how to
> do this.

> Otherwise, I wonder what would be more welcome: making the shared memory
> structs handles available outside of the autovacuum processes (and then
> build an extension to decode the informations I need), or adding functions
> in core to get access to this information (in that case, no need for an
> extension)?

Either one of those approaches would cripple our freedom to change those
data structures; which we've done repeatedly in the past and will surely
want to do again.  So I'm pretty much -1 on exposing them.


I don't see how that's going to deny us the right to change any structs. If they are in-core functions, we'll just have to update them.  If they are extension functions, then the developer of those functions would simply need to update his code.


--

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Publish autovacuum informations
Next
From: Merlin Moncure
Date:
Subject: Re: BUG #12330: ACID is broken for unique constraints