2017-05-13 14:38 GMT+02:00 Amit Kapila <amit.kapil...@gmail.com>:
> On Wed, May 10, 2017 at 10:10 PM, Remi Colinet <remi.coli...@gmail.com>
> > Parallel queries can also be monitored. The same mecanism is used to
> > child workers with a slight difference: the main worker requests the
> > progression directly in order to dump the whole progress tree in shared
> > memory.
> What if there is any error in the worker (like "out of memory") while
> gathering the statistics? It seems both for workers as well as for
> the main backend it will just error out. I am not sure if it is a
> good idea to error out the backend or parallel worker as it will just
> end the query execution.
The handling of progress report starts by the creation of a MemoryContext
attached to CurrentMemoryContext. Then, few memory (few KB) is allocated.
Meanwhile, the handling of progress report could indeed exhaust memory and
fail the backend request. But, in such situation, the backend could also
have fail even without any progress request.
> Also, even if it is okay, there doesn't seem
> to be a way by which a parallel worker can communicate the error back
> to master backend, rather it will just exit silently which is not
If a child worker fails, it will not respond to the main backend request.
The main backend will follow up it execution after a 5 seconds timeout (GUC
param to be added may be). In which case, the report would be partially
If the main backend fails, the requesting backend will have a response such
test=# PROGRESS 14611;
and the child workers will log their response to the shared memory. This
response will not be collected by the main backend which has failed.
Thx & regards
> With Regards,
> Amit Kapila.
> EnterpriseDB: http://www.enterprisedb.com