https://bugs.openldap.org/show_bug.cgi?id=5344
OndÅ™ej KuznÃk <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |IN_PROGRESS
Ever confirmed|0 |1
--- Comment #11 from OndÅ™ej KuznÃk <ondra(a)mistotebe.net> ---
https://git.openldap.org/openldap/openldap/-/merge_requests/373
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8958
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |IN_PROGRESS
Ever confirmed|0 |1
--- Comment #34 from Howard Chu <hyc(a)openldap.org> ---
Indexer fix in https://git.openldap.org/openldap/openldap/-/merge_requests/372
--
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 #33 from Hallvard Furuseth <h.b.furuseth(a)usit.uio.no> ---
On 04.08.2021 13:26, openldap-its(a)openldap.org wrote:
> https://bugs.openldap.org/show_bug.cgi?id=8958
>
> --- Comment #32 from Howard Chu <hyc(a)openldap.org> ---.
> (...)
> If you still believe there's a potential problem with more than
> one pause request a time, your patch might still be useful but
> it will need to be adapted for the multiple queues in 2.5. Nothing
> is going to be changed for 2.4.
Right. The patch is demo code for 2.4 because that was simplest. I
wasn't going to do more work for a feature which might get rejected.
Ondřej, I'm guessing the use of a "scratch" database belongs in
a separate issue and will get lost if left lingering in this one,
since it's a much bigger issue.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6949
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|IN_PROGRESS |RESOLVED
Resolution|--- |TEST
--- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Commits:
• 9f4de680
by Howard Chu at 2021-08-05T15:45:19+00:00
ITS#6949 add support for logfile rotation
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6785
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|ondra(a)mistotebe.net |bugs(a)openldap.org
Target Milestone|2.6.0 |---
--- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Not fully fixed, needs additional work
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7239
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|ondra(a)mistotebe.net |hyc(a)openldap.org
Target Milestone|2.6.0 |2.7.0
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9122
--- Comment #2 from OndÅ™ej KuznÃk <ondra(a)mistotebe.net> ---
I thought we might let the backend know if it's in dryrun mode, but a large
part of slapadd is gated on !dryrun and that would need sweeping changes.
One of those options would be to change bi_tool_entry_open() signature and pass
dryrun in, letting the backend decide whether this should be preserved. bconfig
could then set cfb->cb_use_ldif = 0 and thus any changes would be transient
while still loading all modules etc.
--
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 #32 from Howard Chu <hyc(a)openldap.org> ---
(In reply to Hallvard Furuseth from comment #31)
> 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".
I'm working it out now. As for reactiveness, that depends only
on how much data we index in one chunk, not on the overall size
of the DB.
If you still believe there's a potential problem with more than
one pause request a time, your patch might still be useful but
it will need to be adapted for the multiple queues in 2.5. Nothing
is going to be changed for 2.4.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7048
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.