Hi Jiunn-Yang, Thanks for the updates. I really love the simplification! :)
It seems the KIP page is a bit out-of-date now. Would you mind updating the KIP to match the above discussion? For example, the KIP still uses two timestamps. Plus, we need to describe the risk caused by server time skew that you mentioned. Best, Chia-Ping 黃竣陽 <[email protected]> 於 2026年3月16日週一 下午10:53寫道： > Hello all, > > Thanks for all feedbacks, > > I believe we can simplify the approach further. Instead of comparing group > creation > time against partition creation time to decide between EARLIEST and > LATEST, we > can just always use the group creation timestamp to issue a > ListOffsetsRequest for > all partitions — whether there is no committed offset or the committed > offset is out of > range. If the partition was created after the group, the lookup will > naturally resolve to > the beginning of that partition. If the partition predates the group, the > lookup will find the > first message at or after the group's creation time. Even for the > out-of-range case (e.g., > AdminClient.deleteRecords or log segment deletion), the same rule applies. > > This approach is also more semantically accurate. The name by_start_time > implies > "start consuming from when my group started." Using the group creation > timestamp > as the sole reference point for all scenarios is exactly what this name > promises — > no hidden branching between EARLIEST and LATEST, no conditional > comparisons. > The behavior directly reflects the name. > > This eliminates all conditional logic — the behavior becomes a single, > predictable rule: > always seek to the group's creation time. This simplification also aligns > well with the basic > rule proposed earlier in the discussion: the strategy only affects the > initial startup decision, > and after startup, the behavior remains consistent — we always try to > consume as much > data as possible regardless of the scenario. > > Additionally, this reduces the scope of the protocol change, since we no > longer need to pass > partition creation timestamps in the heartbeat response. Only the group > creation time is required. > > There are two points still worth discussing: Server clock accuracy: > > 1, The broker's clock may have some drift, which could affect the > precision of the timestamp-based > lookup. However, this is equally true for the previous approach that > compared two server-side > timestamps, so it does not introduce a new concern. > > 2. User data timestamps: If producers set custom timestamps on their > records that do not reflect real > time, the ListOffsetsRequest may return unexpected results. However, this > is fundamentally a data > quality issue that users should be responsible for. > > > Best Regards, > Jiunn-Yang > > > jian fu <[email protected]> 於 2026年3月16日 晚上8:10 寫道： > > > > Hi all, > > > > Thank you for introducing/discussion this KIP to address a long-standing > > issue for users. > > > > I think the current issue with the strategy is not only the data loss > > during partition expansion, but also that it is difficult for users to > > understand or remember in different scenarios. > > > > If we can define one basic rule and get agreed in the KIP, it would make > it > > easier for everyone to stay on the same page. > > > > The basic rule would be: > > > > 1 The strategy only affects the initial startup of the consumer, to > decide > > whether historical data should be discarded. > > 2 After startup, no matter which strategy is used, the behavior should > > remain the same: > > > > 2.1 we try not to lose any data. For example, in cases like partition > > expansion, > > 2.2 we should still attempt to consume all available data in future. If > > some data loss is unavoidable, such as when the start offset changes > (e.g., > > due to slow consumption or user-triggered data deletion), we should lose > > the same amount of data regardless of the strategy. This would require a > > small behavior change. Previously, when an out-of-range situation > occurred > > because of a start offset change, the latest strategy could lose more > data > > than earliest .After change, both strategies would behave the same: they > > would reset to the start offset (earliest available offset), which will > > also reduces the number of dropped messages. > > > > I think this rule would significantly reduce the difficulty for users to > > understand the behavior or confuse for some cases. Users would only need > to > > focus on the initial start of the consume group, and there would be no > > differences in behavior in future scenarios. > > > > WDTY? Thanks > > > > Regards > > > > Jian > > > > Ryan Leslie (BLOOMBERG/ NEW YORK) <[email protected]> 于2026年3月16日周一 > > 08:39写道： > > > >> Hey Chia, > >> > >> Sorry, I see the KIP had some recent updates. I see the current idea is > to > >> store partition time and group start time. I think this is good. For > the 2a > >> case (stale offset) it mentions the user is explicitly reset to > earliest if > >> they use by_start_time. As you said, they could use by_duration instead > to > >> avoid a backlog but according to the KIP there is possibility of data > loss > >> during partition expansion. But I agree with you that it's fair to > assume > >> most using this feature are interested in data completeness, and users > are > >> still free to manually adjust offsets. > >> > >> One other comment is the feature may be tricky for users to fully grasp > >> since it combines multiple things. Most users won't really know what > their > >> exact group startup time is. If an offset was deleted, when consuming > >> starts again it might end up being reset to earliest, or some other time > >> that they are not too aware of. It's less deterministic than before. > And if > >> the offset is out of range, then instead they just always get earliest, > >> independent of the group start time. And that behavior is a bit > different > >> than the other one. While this may be sound reasoning to kafka devs, > having > >> users understand what behavior to expect can be harder. The > documentation > >> might be difficult if it has to list out and explain all the cases as > the > >> KIP does. > >> > >> The deleteRecords / stale offset use case is perhaps a separate one from > >> partition expansion. We have sort of combined them into the one > opinionated > >> feature now. > >> > >> Regardless, thank you guys once again for focusing on this long-lived > >> issue in Kafka :) > >> > >> From: [email protected] At: 03/15/26 18:30:45 UTC-4:00To: > >> [email protected] > >> Subject: Re: [DISCUSS] KIP-1282: Prevent data loss during partition > >> expansion for dynamically added partitions > >> > >> Hi Ryan, > >> > >> It seems to me the by_duration policy is already perfectly suited to > tackle > >> the long downtime scenario (Case 2a). > >> > >> If a user wants to avoid a massive backlog after being offline for a > long > >> time, they can configure something like by_duration=10m. > >> > >> This allows them to skip the massive backlog of older records, while > still > >> capturing the most recent data (including anything in newly expanded > >> partitions). > >> > >> Since by_duration and latest already serve the users who want to skip > data, > >> shouldn't by_start_time remain strictly focused on users whose primary > goal > >> is data completeness (even if it means processing a backlog)? > >> > >> Best, > >> Chia-Ping > >> > >> Ryan Leslie (BLOOMBERG/ NEW YORK) <[email protected]> 於 > 2026年3月16日週一 > >> 上午4:57寫道： > >> > >>> Hey Chia, > >>> > >>> That's an interesting point that there is another subcase, 2c, caused > by > >>> the user having deleted records. While the current behavior of 'latest' > >>> would not be changed by adding something like 'auto.no.offset.reset' > >>> mentioned earlier, the current suggestion of by_start_time would > address > >>> not only the case of newly added partitions, but this additional case > >> when > >>> records are deleted and the offset is invalid. It may be worth > explicitly > >>> highlighting this as another intended use case in the KIP. > >>> > >>> Also, have you given anymore thought to the case where a consumer > crashes > >>> during the partition expansion and its timestamp is lost or incorrect > >> when > >>> it restarts? If we decided to do something where the timestamp is just > >>> stored by the broker as the creation time of the consumer group, then > >> after > >>> a short while (a typical retention period) it may just degenerate into > >>> 'earliest' anyway. In that case the behavior of 2a is also implicitly > >>> changed to 'earliest' which again the user may not want since they > >>> intentionally had the consumer down. This is why I feel it can get kind > >> of > >>> confusing to try to cover all reset cases in a single tunable, > >>> auto.offset.reset. It's because there are several different cases. > >>> > >>> From: [email protected] At: 03/15/26 10:44:06 UTC-4:00To: > >>> [email protected] > >>> Subject: Re: [DISCUSS] KIP-1282: Prevent data loss during partition > >>> expansion for dynamically added partitions > >>> > >>> Hi Ryan, > >>> > >>> Thanks for the detailed breakdown! Categorizing the scenarios into 1a, > >> 1b, > >>> and > >>> 2a is incredibly helpful. We are completely aligned that Case 1b (a > newly > >>> added > >>> partition) is the true issue and the primary motivation for this KIP. > >>> > >>> Regarding the "out of range" scenario (Case 2a), the situation you > >>> described (a > >>> consumer being offline for a long time) is very real. However, I'd like > >> to > >>> offer another common operational perspective: > >>> > >>> What if a user explicitly uses AdminClient.deleteRecords to advance the > >>> start > >>> offset just to skip a batch of corrupted/poison-pill records? > >>> > >>> In this scenario, the consumer hasn't been hanging or offline for long; > >> it > >>> simply hits an OffsetOutOfRange error. If we force the policy to jump > to > >>> latest, the consumer will unexpectedly skip all the remaining healthy > >>> records > >>> up to the High Watermark. This would cause massive, unintended data > loss > >>> for an > >>> operation that merely meant to skip a few bad records. > >>> > >>> Therefore, to make the semantic guarantee accurate and predictable: if > a > >>> user > >>> explicitly opts into policy=by_start_time (meaning "I want every record > >>> since I > >>> started"), our contract should be to let them process as much surviving > >>> data as > >>> possible. Falling back to earliest during an out-of-range event > fulfills > >>> this > >>> promise safely. > >>> > >>> On 2026/03/13 23:07:04 "Ryan Leslie (BLOOMBERG/ NEW YORK)" wrote: > >>>> Hi Chia, > >>>> > >>>> I have a similar thought that knowing if the consumer group is new is > >>> helpful. It may be possible to avoid having to know the age of the > >>> partition. > >>> Thinking out loud a bit here, but: > >>>> > >>>> The two cases for auto.offset.reset are: > >>>> > >>>> 1. no offset > >>>> 2. offset is out of range > >>>> > >>>> These have subcases such as: > >>>> > >>>> 1. no offset > >>>> a. group is new > >>>> b. partition is new > >>>> c. offset previously existed was explicitly deleted > >>>> > >>>> 2. offset is out of range > >>>> a. group has stopped consuming or had no consumers for a while, > >> offset > >>> is > >>> stale > >>>> b. invalid offset was explicitly committed > >>>> > >>>> Users of auto.offset.reset LATEST are perhaps mostly interested in not > >>> processing a backlog of messages when they first start up. But if there > >> is > >>> a > >>> new partition they don't want to lose data. A typical user might want: > >>>> > >>>> 1a - latest > >>>> > >>>> 1b - earliest > >>>> > >>>> 1c - Unclear, but this may be an advanced user. Since they may have > >>> explicitly used AdminClient to remove the offset, they can explicitly > use > >>> it to > >>> configure a new one > >>>> > >>>> 2a - latest may be appropriate - the group has most likely already > lost > >>> messages > >>>> > >>>> 2b - Similar to 2c, this may be an advanced user already in control > >> over > >>> offsets with AdminClient > >>>> > >>>> If we worry most about cases 1a, 1b, and 2a, only 1b is the exception > >>> (which > >>> is why this KIP exists). What we really want to know is if partition is > >>> new, > >>> but perhaps as long as we ensure that 1a and 2a are more explicitly > >>> configurable, > >>>> then we may get support for 1b without a partition timestamp. For > >>> example, if > >>> the following new config existed: > >>>> > >>>> Applies if the group already exists and no offset is committed for a > >>> partition. Group existence is defined as the group already having some > >>> offsets > >>> committed for partitions. Otherwise, auto.offset.reset applies. > >>>> Note: we could possibly make this not applicable to static partition > >>> assignment cases > >>>> > >>>> auto.no.offset.reset = earliest > >>>> > >>>> Handles all other cases as it does today. auto.no.offset.resets take > >>> precedence > >>>> > >>>> auto.offset.reset = latest > >>>> > >>>> The question is if the consumer can reliably determine if the group is > >>> new > >>> (has offsets or not) since there may be multiple consumers all > committing > >>> at > >>> the same time around startup. Otherwise we would have to rely on the > fact > >>> that > >>> the new consumer protocol centralizes things > >>>> through the coordinator, but this may require more significant changes > >>> as you > >>> mentioned... > >>>> > >>>> I agree with Jiunn that we could consider supporting the > >>> auto.offset.reset > >>> timestamp separately, but I'm still concerned about the case where a > >>> consumer > >>> crashes during the partition expansion and it's timestamp is lost or > >>> incorrect > >>> when it restarts. A feature with a false sense of security can be > >>> problematic. > >>>> > >>>> From: [email protected] At: 03/10/26 04:02:58 UTC-4:00To: > >>> [email protected] > >>>> Subject: Re: [DISCUSS] KIP-1282: Prevent data loss during partition > >>> expansion > >>> for dynamically added partitions > >>>> > >>>> Hi Ryan, > >>>> > >>>> Thanks for sharing your thoughts! We initially tried to leave the RPCs > >> as > >>>> they were, but you're absolutely right that the current KIP feels a > bit > >>>> like a kludge. > >>>> > >>>> If we are open to touching the protocol (and can accept the potential > >>> time > >>>> skew between nodes), I have another idea: what if we add a creation > >>>> timestamp to both the partition and the group? > >>>> > >>>> This information could be returned to the consumer via the new > >> Heartbeat > >>>> RPC. The async consumer could then seamlessly leverage these > timestamps > >>> to > >>>> make a deterministic decision between using "latest" or "earliest." > >>>> > >>>> This approach would only work for the AsyncConsumer using subscribe() > >>>> (since it relies on the group state), which actually serves as another > >>>> great incentive for users to migrate to the new consumer! > >>>> > >>>> Thoughts on this direction? > >>>> > >>>> Best, > >>>> > >>>> Chia-Ping > >>>> > >>>> Ryan Leslie (BLOOMBERG/ NEW YORK) <[email protected]> 於 > >> 2026年3月10日週二 > >>>> 上午6:38寫道： > >>>> > >>>>> Hi Chia and Jiunn, > >>>>> > >>>>> Thanks for the response. I agree that the explicit timestamp gives > >>> enough > >>>>> flexibility for the user to avoid the issue I mentioned with the > >>> implicit > >>>>> timestamp at startup not matching the time the group instance > >> started. > >>>>> > >>>>> One potential downside is that the user may have to store this > >>> timestamp > >>>>> somewhere in between restarts. For the group instance id, that is not > >>>>> always the case since sometimes it can be derived from the > >> environment > >>> such > >>>>> as the hostname, or hardcoded in an environment variable where it > >>> typically > >>>>> doesn't need to be updated. > >>>>> > >>>>> Also, since static instances may be long-lived, preserving just the > >>>>> initial timestamp of the first instance might feel a bit awkward, > >>> since you > >>>>> may end up with static instances restarting and passing timestamps > >> that > >>>>> could be old like two months ago. The user could instead store > >>> something > >>>>> like the last time of restart (and subtract metadata max age from it > >>> to be > >>>>> safe), but it can be considered a burden and may fail if shutdown was > >>> not > >>>>> graceful, i.e. a crash. > >>>>> > >>>>> I agree that this KIP provides a workable solution to avoid data loss > >>>>> without protocol or broker changes, so I'm +1. But it does still > >> feel a > >>>>> little like a kludge since what the user really needs is an easy, > >>> almost > >>>>> implicit, way to not lose data when a recently added partition is > >>>>> discovered, and currently there is no metadata for the creation time > >>> of a > >>>>> partition. The user may not want to even have the same policy applied > >>> to > >>>>> older partitions for which their offset was deleted. > >>>>> > >>>>> Even for a consumer group not using static membership, suppose > >>> partitions > >>>>> are added by a producer and new messages are published. If at the > >> same > >>> time > >>>>> there is consumer group, e.g. with 1 consumer only, and it has > >> crashed, > >>>>> when it comes back up it may lose messages unless it knows what > >>> timestamp > >>>>> to pass. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Ryan > >>>>> > >>>>> From: [email protected] At: 03/07/26 02:46:28 UTC-5:00To: > >>>>> [email protected] > >>>>> Subject: Re: [DISCUSS] KIP-1282: Prevent data loss during partition > >>>>> expansion for dynamically added partitions > >>>>> > >>>>> Hello Sikka, > >>>>> > >>>>>> If consumer restarts (app crash, bounce etc.) after dynamically > >>> adding > >>>>> partitions > >>>>>> it would consume unread messages from last committed offset for > >>> existing > >>>>>> partitions but would still miss the messages from new partition. > >>>>> > >>>>> For dynamic consumers, a restart inherently means leaving and > >> rejoining > >>>>> the > >>>>> group > >>>>> as a new member, so recalculating startupTimestamp = now() is > >>> semantically > >>>>> correct — > >>>>> the consumer is genuinely starting fresh. > >>>>> > >>>>> The gap you described only applies to static membership, where the > >>>>> consumer can > >>>>> restart > >>>>> without triggering a rebalance, yet the local timestamp still gets > >>> reset. > >>>>> For > >>>>> this scenario, as > >>>>> Chia suggested, we could extend the configuration to accept an > >> explicit > >>>>> timestamp > >>>>> This would allow users to pin a fixed reference point across > >> restarts, > >>>>> effectively closing the gap for > >>>>> static membership. For dynamic consumers, the default by_start_time > >>>>> without an > >>>>> explicit timestamp > >>>>> already provides the correct behavior and a significant improvement > >>> over > >>>>> latest, which would miss > >>>>> data even without a restart. > >>>>> > >>>>>> If the offset are deleted mention in mentioned in Scenario 2 (Log > >>>>> truncation) > >>>>>> how this solution would address that scenario ? > >>>>> > >>>>> For the log truncation scenario, when segments are deleted and the > >>>>> consumer's > >>>>> committed > >>>>> offset becomes out of range, auto.offset.reset is triggered. With > >>> latest, > >>>>> the > >>>>> consumer simply jumps > >>>>> to the end of the partition, skipping all remaining available data. > >>> With > >>>>> by_start_time, the consumer looks up > >>>>> the position based on the startup timestamp rather than relying on > >>>>> offsets. > >>>>> Since the lookup is timestamp-based, > >>>>> it is not affected by offset invalidation due to truncation. Any data > >>> with > >>>>> timestamps at or after the startup time > >>>>> will still be found and consumed. > >>>>> > >>>>>> Do we need to care about Clock Skew or SystemTime Issues on > >> consumer > >>>>> client > >>>>> side. > >>>>>> Should we use timestamp on the server/broker side ? > >>>>> > >>>>> Clock skew is a fair concern, but using a server-side timestamp does > >>> not > >>>>> necessarily make things safer. > >>>>> It would mean comparing the Group Coordinator's time against the > >>> Partition > >>>>> Leader's time, which are often > >>>>> different nodes. Without strict clock synchronization across the > >> Kafka > >>>>> cluster, > >>>>> this "happens-before" relationship > >>>>> remains fundamentally unpredictable. On the other hand, > >>> auto.offset.reset > >>>>> is > >>>>> strictly a client-level configuration — > >>>>> consumers within the same group can intentionally use different > >>> policies. > >>>>> Tying > >>>>> the timestamp to a global server-side > >>>>> state would be a semantic mismatch. A local timestamp aligns much > >>> better > >>>>> with > >>>>> the client-level nature of this config. > >>>>> > >>>>>> Do you plan to have any metrics or observability when consumer > >> resets > >>>>> offset > >>>>> by_start_time > >>>>> > >>>>> That's a great suggestion. I plan to expose the startup timestamp > >> used > >>> by > >>>>> by_start_time as a client-level metric, > >>>>> so users can easily verify which reference point the consumer is > >> using > >>>>> during > >>>>> debugging. > >>>>> > >>>>> Best Regards, > >>>>> Jiunn-Yang > >>>>> > >>>>>> Chia-Ping Tsai <[email protected]> 於 2026年3月6日 晚上10:44 寫道： > >>>>>> > >>>>>> Hi Ryan, > >>>>>> > >>>>>> That is a fantastic point. A static member restarting and > >> capturing a > >>>>> newer > >>>>> local timestamp is definitely a critical edge case. > >>>>>> > >>>>>> Since users already need to inject a unique group.instance.id into > >>> the > >>>>> configuration for static members, my idea is to allow the > >>>>> auto.offset.reset > >>>>> policy to carry a dedicated timestamp to explicitly "lock" the > >> startup > >>>>> time > >>>>> (for example, using a format like > >>> auto.offset.reset=startup:<timestamp>). > >>>>>> > >>>>>> This means that if users want to leverage this new policy with > >> static > >>>>> membership, their deployment configuration would simply include these > >>> two > >>>>> specific injected values (the static ID and the locked timestamp). > >>>>>> > >>>>>> This approach elegantly maintains the configuration semantics at > >> the > >>>>> member-level, and most importantly, it avoids any need to update the > >>> RPC > >>>>> protocol. > >>>>>> > >>>>>> What do you think of this approach for the static membership > >>> scenario? > >>>>>> > >>>>>> On 2026/03/05 19:45:13 "Ryan Leslie (BLOOMBERG/ NEW YORK)" wrote: > >>>>>>> Hey Jiunn, > >>>>>>> > >>>>>>> Glad to see some progress around this issue. > >>>>>>> > >>>>>>> I had a similar thought to David, that if the time is only known > >>> client > >>>>> side > >>>>> there are still edge cases for data loss. One case is static > >> membership > >>>>> where > >>>>> from the perspective of a client they are free to restart their > >>> consumer > >>>>> task > >>>>> without actually having left or meaningfully affected the group. > >>> However, > >>>>> I > >>>>> think with the proposed implementation the timestamp is still reset > >>> here. > >>>>> So if > >>>>> the restart happens just after a partition is added and published to, > >>> but > >>>>> before the consumer metadata refreshed, the group still runs the risk > >>> of > >>>>> data > >>>>> loss. > >>>>>>> > >>>>>>> It could be argued that keeping the group 'stable' is a > >> requirement > >>> for > >>>>> this > >>>>> feature to work, but sometimes it's not possible to accomplish. > >>>>>>> > >>>>>>> From: [email protected] At: 03/05/26 14:32:20 UTC-5:00To: > >>>>> [email protected] > >>>>>>> Subject: Re: [DISCUSS] KIP-1282: Prevent data loss during > >> partition > >>>>> expansion for dynamically added partitions > >>>>>>> > >>>>>>> Hi Jiunn, > >>>>>>> > >>>>>>> Thanks for the KIP! > >>>>>>> > >>>>>>> I was also considering this solution while we discussed in the > >>> jira. It > >>>>>>> seems to work in most of the cases but not in all. For instance, > >>> let’s > >>>>>>> imagine a partition created just before a new consumer joins or > >>> rejoins > >>>>> the > >>>>>>> group and this consumer gets the new partition. In this case, the > >>>>> consumer > >>>>>>> will have a start time which is older than the partition creation > >>> time. > >>>>>>> This could also happen with the truncation case. It makes the > >>> behavior > >>>>> kind > >>>>>>> of unpredictable again. > >>>>>>> > >>>>>>> Instead of relying on a local timestamp, one idea would to rely > >> on a > >>>>>>> timestamp provided by the server. For instance, we could define > >> the > >>> time > >>>>>>> since the group became non-empty. This would define the > >> subscription > >>>>> time > >>>>>>> for the consumer group. The downside is that it only works if the > >>>>> consumer > >>>>>>> is part of a group. > >>>>>>> > >>>>>>> In your missing semantic section, I don’t fully understand how the > >>> 4th > >>>>>>> point is improved by the KIP. It says start from earliest but with > >>> the > >>>>>>> change it would start from application start time. Could you > >>> elaborate? > >>>>>>> > >>>>>>> Best, > >>>>>>> David > >>>>>>> > >>>>>>> Le jeu. 5 mars 2026 à 12:47, 黃竣陽 <[email protected]> a écrit : > >>>>>>> > >>>>>>>> Hello chia, > >>>>>>>> > >>>>>>>> Thanks for your feedback, I have updated the KIP. > >>>>>>>> > >>>>>>>> Best Regards, > >>>>>>>> Jiunn-Yang > >>>>>>>> > >>>>>>>>> Chia-Ping Tsai <[email protected]> 於 2026年3月5日 晚上7:24 寫道： > >>>>>>>>> > >>>>>>>>> hi Jiunn > >>>>>>>>> > >>>>>>>>> chia_00: Would you mind mentioning KAFKA-19236 in the KIP? It > >>> would be > >>>>>>>> helpful to let readers know that "Dynamically at partition > >>> discovery" > >>>>> is > >>>>>>>> being tracked as a separate issue > >>>>>>>>> > >>>>>>>>> Best, > >>>>>>>>> Chia-Ping > >>>>>>>>> > >>>>>>>>> On 2026/03/05 11:14:31 黃竣陽 wrote: > >>>>>>>>>> Hello everyone, > >>>>>>>>>> > >>>>>>>>>> I would like to start a discussion on KIP-1282: Prevent data > >> loss > >>>>>>>> during partition expansion for dynamically added partitions > >>>>>>>>>> <https://cwiki.apache.org/confluence/x/mIY8G> > >>>>>>>>>> > >>>>>>>>>> This proposal aims to introduce a new auto.offset.reset policy > >>>>>>>> by_start_time, anchoring the > >>>>>>>>>> offset reset to the consumer's startup timestamp rather than > >>>>> partition > >>>>>>>> discovery time, to prevent > >>>>>>>>>> silent data loss during partition expansion. > >>>>>>>>>> > >>>>>>>>>> Best regards, > >>>>>>>>>> Jiunn-Yang > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > >> > >
