389-ds-base

#51020 Evaluate if performance counters should be preserved during backup restore
Closed: wontfix by spichugi. Opened by spichugi.

Closed: wontfix
Reopen Issue

Issue Description

While working on a fix for #51016, I found that we have a controversial situation.

ldbm_back_archive2ldbm:

  • In one place, we use DBLAYER_RESTORE_MODE during dblayer_close to prevent loss of perfctrs memory:
    https://pagure.io/389-ds-base/blob/master/f/ldap/servers/slapd/back-ldbm/archive.c#_152

  • And later in the code during dblayer_restore, we initialize perfctrs memory once again and we rewrite the existing pointer with a new one:
    https://pagure.io/389-ds-base/blob/master/f/ldap/servers/slapd/back-ldbm/archive.c#_158
    https://pagure.io/389-ds-base/blob/master/f/ldap/servers/slapd/back-ldbm/db-bdb/bdb_layer.c#_1297

We have to decide what we want here. Two options are present:

  1. Reset the counters after the backup restore.
  2. Preserve the counters and don't initialize during dblayer_restore.

Package Version and Platform

389-ds-base-1.4.3.5-20200409git36c593d32.fc31.x86_64

Metadata Update from @mreynolds:
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Issue priority set to: minor
- Issue set to the milestone: 1.4.4

Is there a value in restoring the counters?

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/4073

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
Highest
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.