Re: syncrepl'd MOD deleted entry (ITS#4365)

[richton@nbcs.rutgers.edu]

I installed a heavily patched 2.3.18 (just short of "being 2.3.19") last
night on test slave5, and across the board this morning after it didn't
segv overnight. I then re-synced all the databases, and did a diff to make
sure that I had a valid "slaves syncrepl'd consistent" starting point
which I could stress with MODs. But I'm not even at my starting point yet:

Jan 24 12:03:06 master.rutgers.edu slapd[6125]: [ID 585459 local4.debug]
conn=11919 op=5 ADD dn="uid=test0,ou=People,dc=eden,dc=rutgers,dc=edu"
Jan 24 12:04:23 slave3.rutgers.edu slapd[19187]: [ID 260518 local4.debug]
syncrepl_entry: uid=test0,ou=People,dc=eden,dc=rutgers,dc=edu
Jan 24 12:06:17 slave5.rutgers.edu slapd[28305]: [ID 260518 local4.debug]
syncrepl_entry: uid=test0,ou=People,dc=eden,dc=rutgers,dc=edu
Jan 24 12:06:44 slave1.rutgers.edu slapd[18606]: [ID 260518 local4.debug]
syncrepl_entry: uid=test0,ou=People,dc=eden,dc=rutgers,dc=edu
Jan 24 12:33:06 master.rutgers.edu slapd[6125]: [ID 379477 local4.debug]
conn=12943 op=2 DEL dn="uid=test0,ou=People,dc=eden,dc=rutgers,dc=edu"


uid=test0 is present on slave1 and slave5. slave2 was in the process of
reloading at that time, and slave3 was reloaded later. We can (almost?)
surmise that it never got deleted.

Now, this was almost a hopeful situation, because slave5 is the debugging
one.  Unfortunately, the pitfalls of a 0600 downtime window, I turned it
back on with the production init script instead of -d at the command line.
Augh! So the above (or a dbx attach to any of those pids?) is all I can
offer on this. I'll keep playing and report, but if there's anything
obvious with syncrepl DEL, that would be good to consider for 2.3.19.