From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Marc Cousin <marc(dot)cousin(at)dalibo(dot)com> |
Subject: | Re: Issue with bgworker, SPI and pgstat_report_stat |
Date: | 2016-07-07 18:04:36 |
Message-ID: | CA+TgmobO1pLrEnrB+=uETqA89DHsKRLiDrisvscJfvXPDnKAYA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 7, 2016 at 1:52 PM, Julien Rouhaud
<julien(dot)rouhaud(at)dalibo(dot)com> wrote:
> While investigating on a bloat issue with a colleague, we found that if
> a bgworker executes some queries with SPI, the statistic changes will
> never be reported, since pgstat_report_stat() is only called in regular
> backends.
>
> In our case, the bgworker is the only process inserting and deleting a
> large amount of data on some tables, so the autovacuum never tried to do
> any maintenance on these tables.
Ouch.
> Should a bgworker modifing data have to call pgstat_report_stat() to
> avoid this problem? I don't find any documentation suggesting it, and it
> seems that worker_spi (used as a template for this bgworker and I
> suppose a lot of other one) is also affected.
That certainly seems like the simplest fix. Not sure if there's a better one.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-07-07 18:04:37 | Re: Reviewing freeze map code |
Previous Message | Robert Haas | 2016-07-07 18:01:05 | Re: Reviewing freeze map code |