https://bugs.openldap.org/show_bug.cgi?id=3460
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=2914
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=2767
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=2571
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=2410
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7283
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7054
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=2560
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8591
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8958
--- Comment #31 from Hallvard Furuseth <h.b.furuseth(a)usit.uio.no> ---
On 03.08.2021 14:42, openldap-its(a)openldap.org wrote:
> https://bugs.openldap.org/show_bug.cgi?id=8958
>
> --- Comment #26 from Howard Chu <hyc(a)openldap.org> ---
> I don't think we should be changing anything else about how tpool
> handles pauses. We should just be fixing this specific case of the
> indexer being a slow task, by implementing checkpointing into the
> indexer. I.e., when it detects a pause request it should save its
> current progress and pause itself. If it gets resumed it can pick up
> where it left off, or if a config change affects it it can abort or
> or start over. A checkpointing mechanism is needed anyway, for the
> case of a (clean) shutdown while the indexer is running.
For fixing the observed problem:
Improving the indexer sounds great in any case, go ahead:-)
No idea how much work it is. tpool.c was code I knew how
to change, so I did.
Will it then be as reactive as ordinary tasks, also for
large databases? Merely "much faster than now" might be
very different from "fast enough to not be a problem".
In general:
I do think slapd should recognize that some tasks can be notably
slower that others. Latency is in part a scheduling issue, and
it can hit particularly hard at pauses. Currently tpool does
not help with that. Setspeed can help.
Except if a run-time config change removes the database/overlay,
I'm not up to date about whether that can happen. But that's
so for rescheduling the indexer as well.
back-sock/back-shell can also be slow, so I expect they have the
same issue. If they "fix" that with pool_idle() before reading
results, I expect config changes could hose the operation badly.
Same with setspeed() in the backend, it'd be too late. Maybe if
the database declared itself "slow", then slapd could setspeed()
before dispatching the operation to the database.
Hallvard
--
You are receiving this mail because:
You are on the CC list for the issue.