Re: Issue with bgworker, SPI and pgstat_report_stat - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Issue with bgworker, SPI and pgstat_report_stat
Date
Msg-id CAMsr+YEhMNaVqPQdyhkWXdJ9ey+htgK7DwtBfzBM6Md04LiAHw@mail.gmail.com
Whole thread Raw
In response to Re: Issue with bgworker, SPI and pgstat_report_stat  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Issue with bgworker, SPI and pgstat_report_stat  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pgbench - minor doc improvements
Next
From: Craig Ringer
Date:
Subject: Re: Logical decoding