Re: Issue with bgworker, SPI and pgstat_report_stat

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: Issue with bgworker, SPI and pgstat_report_stat
Дата
Msg-id CAMsr+YEhMNaVqPQdyhkWXdJ9ey+htgK7DwtBfzBM6Md04LiAHw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Issue with bgworker, SPI and pgstat_report_stat  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Issue with bgworker, SPI and pgstat_report_stat  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
On 11 July 2016 at 11:49, Michael Paquier <michael.paquier@gmail.com> wrote:
On Mon, Jul 11, 2016 at 3:36 AM, Julien Rouhaud
<julien.rouhaud@dalibo.com> wrote:
> I'm not opposed, but in this case we should also provide a proper
> documentation of all the required actions to mimick normal backends.

I'd rather just add a note like "Have a look at PostgresMain if you
want to imitate a backend able to run queries!" instead of listing all
the actions doable. If low-level things are added or removed in the
future in PostgresMain, it is very likely that the documentation will
not be updated at the same time, killing its purpose at the end.

That sounds like a bug breeding ground. Especially with extensions whose bgworkers operate across Pg versions, extensions that get updated without re-checking PostgresMain and don't notice some new housekeeping task, etc.

Rather than encouraging every extension author to copy and paste random chunks of PostgresMain, probably incorrectly, I really think factoring the required logic out into something reusable by bgworkers is going to be the way to go.  
 
--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pgbench - minor doc improvements
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: Logical decoding