On Fri, Jul 5, 2019 at 7:39 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Jun 25, 2019 at 4:00 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > Fair enough. I have implemented it based on next_retry_at and use
> > constant time 10s for the next retry. I have used define instead of a
> > GUC as all the other constants for similar things are defined as of
> > now. One thing to note is that we want the linger time (defined as
> > UNDO_WORKER_LINGER_MS) for a undo worker to be more than failure retry
> > time (defined as UNDO_FAILURE_RETRY_DELAY_MS) as, otherwise, the undo
> > worker can exit before retrying the failed requests.
>
> Uh, I think we want exactly the opposite. We want the workers to exit
> before retrying, so that there's a chance for other databases to get
> processed, I think.
>
The workers will exit if there is any chance for other databases to
get processed. Basically, we linger only when we find there is no
work in other databases. Not only that even if some new work is added
to the queues for some other database then also we stop the lingering
worker if there is no worker available for the new request that has
arrived.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com