Hi Enrico, I don't think they conflict. We can do them separately.
We can add the policy to the per topic and per namespace again when we need it in the future, and the current PIP can just add a configuration to broker.conf first so that we can not retain the null-key messages and cherry-pick this fix into other branches with `compactionRemainNullKey=true` default to keep compatibility. Thanks, Cong Zhao On 2023/11/08 07:26:30 Enrico Olivelli wrote: > This is a good point. > > Is it worth to make it configurable per topic and per namespace? > > Even if this behavior is kind if a side effect or bug, maybe some > applications rely on it. > Flags that change the behavior per cluster are hard to adopt in nig cluster > with many tenants. > > We should always take multi tenancy in mind when we design features or > changes. > > > Thanks > Enrico > > Il Mer 8 Nov 2023, 07:55 Cong Zhao <zhaoc...@apache.org> ha scritto: > > > Hello everyone, > > > > I open a PIP-318: https://github.com/apache/pulsar/pull/21541 for this > > discussion. > > > > Any feedback and suggestions are welcome. > > > > Thanks, > > Cong Zhao > > > > On 2023/11/07 02:55:52 Cong Zhao wrote: > > > Hi, Pulsar community > > > > > > Currently, we retain all null-key messages during topic compaction, > > which I > > > don't think is necessary because when you use topic compaction, > > > it means that you want to retain the value according to the key, so > > > retaining null-key messages is meaningless. > > > > > > Additionally, retaining all null-key messages will double the storage > > cost, > > > and we'll never be able to clean them up since the compacted topic has > > not > > > supported the retention policy yet. > > > > > > In summary, I don't think we should retain null-key messages during topic > > > compaction. > > > Looking forward to your feedback! > > > > > > Thanks, > > > Cong Zhao > > > > > >
