Bug 1972590 - Large updates can reset the CLcache to the beginning of the changelog
Summary: Large updates can reset the CLcache to the beginning of the changelog
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: 389-ds-base
Version: 8.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: beta
: ---
Assignee: thierry bordaz
QA Contact: RHDS QE
URL:
Whiteboard: sync-to-jira
Depends On: 1930231
Blocks: 1972721
TreeView+ depends on / blocked
 
Reported: 2021-06-16 09:56 UTC by thierry bordaz
Modified: 2022-01-07 09:26 UTC (History)
13 users (show)

Fixed In Version: 389-ds-base-1.4.3.23-3.module+el8.5.0+11463+c476656c
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1930231
: 1972721 (view as bug list)
Environment:
Last Closed: 2021-11-09 18:12:23 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 4644 0 None closed Large updates can reset the CLcache to the beginning of the changelog 2022-01-07 09:26:23 UTC
Red Hat Product Errata RHBA-2021:4203 0 None None None 2021-11-09 18:12:49 UTC

Comment 1 thierry bordaz 2021-06-16 10:16:53 UTC 
Fix is pushed upstream => POST
Comment 7 sgouvern 2021-06-28 14:49:37 UTC 
build 389-ds-base-1.4.3.23-3.module+el8.5.0+11463+c476656c.x86_64.rpm planned for ITM 18 needs a respin - Moving to ITM 19
Comment 8 Akshay Adhikari 2021-07-07 15:32:59 UTC 
Build Tested: 389-ds-base-1.4.3.23-4.module+el8.5.0+11627+16aed726.x86_64


# grep clcache_adjust_anchorcsn  /var/log/dirsrv/slapd-supplier1/errors | grep 'cscb 0 - state 0' | tail -5
[07/Jul/2021:08:14:28.441899616 -0400] - DEBUG - agmt="cn=002" (example:39002) - clcache_adjust_anchorcsn - agmt="cn=002" (example:39002) - (cscb 0 - state 0) - csnPrevMax (60e59aa2002c00010000) csnMax (60e59aa2002c00010000) csnBuf (60e59aa2001e00010000) csnConsumerMax (60e59aa2001e00010000)
[07/Jul/2021:08:48:22.607417989 -0400] - DEBUG - agmt="cn=002" (example:39002) - clcache_adjust_anchorcsn - agmt="cn=002" (example:39002) - (cscb 0 - state 0) - csnPrevMax (60e59cac000000010000) csnMax (60e59cac000000010000) csnBuf (60e59c85000000010000) csnConsumerMax (60e59c85000000010000)
[07/Jul/2021:08:48:28.230611529 -0400] - DEBUG - agmt="cn=002" (example:39002) - clcache_adjust_anchorcsn - agmt="cn=002" (example:39002) - (cscb 0 - state 0) - csnPrevMax (60e59cac000000010000) csnMax (60e59cac000000010000) csnBuf (60e59c8e000000010000) csnConsumerMax (60e59c8e000000010000)
[07/Jul/2021:08:48:33.269883595 -0400] - DEBUG - agmt="cn=002" (example:39002) - clcache_adjust_anchorcsn - agmt="cn=002" (example:39002) - (cscb 0 - state 0) - csnPrevMax (60e59cac000000010000) csnMax (60e59cac000000010000) csnBuf (60e59c95000000010000) csnConsumerMax (60e59c95000000010000)
[07/Jul/2021:08:48:37.952870693 -0400] - DEBUG - agmt="cn=002" (example:39002) - clcache_adjust_anchorcsn - agmt="cn=002" (example:39002) - (cscb 0 - state 0) - csnPrevMax (60e59cac000000010000) csnMax (60e59cac000000010000) csnBuf (60e59ca0000000010000) csnConsumerMax (60e59ca0000000010000)


==> csnBuf and csnConsumerMax are in sync.

Checking jump in the past:
# grep -n '^csn' /var/lib/dirsrv/slapd-supplier1/changelogdb/0b33fe90-df1b11eb-8e23a4c5-56054365.ldif | wc -l
38141

# grep -n '^csn' /var/lib/dirsrv/slapd-supplier1/changelogdb/0b33fe90-df1b11eb-8e23a4c5-56054365.ldif | grep 60e59ca0000000010000
12800632:csn: 60e59ca0000000010000


-> Marking as verified: tested
Comment 11 sgouvern 2021-07-12 07:59:04 UTC 
As per comment 8, marking as VERIFIED
Comment 13 errata-xmlrpc 2021-11-09 18:12:23 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (389-ds-base bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:4203
Note You need to log in before you can comment on or make changes to this bug.