Re: Publish autovacuum informations

Поиск
Список
Период
Сортировка
От Guillaume Lelarge
Тема Re: Publish autovacuum informations
Дата
Msg-id CAECtzeWUB6cRgEJQM+wf9+TzMEFYHrCzUjGjYQEwEvDNupabNg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Publish autovacuum informations  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Publish autovacuum informations
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: BUG #12330: ACID is broken for unique constraints