In preparation for the upcoming syncrepl changes, I've updated liblutil to generate CSNs with microseconds in the timestamp.
Currently slapd copies the entryCSN timestamp to the createTimestamp and modifyTimestamp attributes when generating these attributes. Anyone have any thoughts on whether it would be a too-surprising change for these attributes to now have higher resolution? Should we keep truncating them to 1-second resolution?
Howard Chu wrote:
In preparation for the upcoming syncrepl changes, I've updated liblutil to generate CSNs with microseconds in the timestamp.
Currently slapd copies the entryCSN timestamp to the createTimestamp and modifyTimestamp attributes when generating these attributes. Anyone have any thoughts on whether it would be a too-surprising change for these attributes to now have higher resolution? Should we keep truncating them to 1-second resolution?
Maybe we should carefully check that appropriately sized buffers are used everywhere in the code, to avoid surprises... this could be a good chance to make sure generalizedTime is handled in exactly one place (which could already be, didn't check recently).
p.
Pierangelo Masarati wrote:
Howard Chu wrote:
In preparation for the upcoming syncrepl changes, I've updated liblutil to generate CSNs with microseconds in the timestamp.
Currently slapd copies the entryCSN timestamp to the createTimestamp and modifyTimestamp attributes when generating these attributes. Anyone have any thoughts on whether it would be a too-surprising change for these attributes to now have higher resolution? Should we keep truncating them to 1-second resolution?
Maybe we should carefully check that appropriately sized buffers are used everywhere in the code, to avoid surprises... this could be a good chance to make sure generalizedTime is handled in exactly one place (which could already be, didn't check recently).
We use LUTIL_GENTIME_BUFSIZE consistently everywhere, so that's not a problem.
I think it might confuse replog and slurpd. If we're still keeping slurpd in 2.4, then that's a reason to keep the stamps truncated to 1-second resolution. Also, we could just decide to keep it as-is "because that's the way it's always been" and only change the CSNs. I guess since we have the CSN, there's no particular advantage to also changing the others.
-
Howard Chu -
Pierangelo Masarati