Trung Dinh

> I think the behavior we want is to evict these layers, but not until an ongoing compaction has finished with them. I think this is what I was trying...

> It'll be important not to end up in a state where a large tenant undergoing compaction can't do any eviction, because that could cause ENOSPC Indeed. But I would...

> the actual code paths that write data (ingest, compaction) don't explicitly check for free space. I see. I was thinking that ingestion should be slowed down if compaction is...

I've just read this epic https://github.com/neondatabase/neon/issues/5331 and there is a mention of a possible solution for this ticket :) Would you mind if I take a stab at this? >...

> That comment is describing a heuristic for alerting on thrashing, rather than something that would actually prevent it. Ah alerting (not altering :) ) i can help with first...

> I don't really understand what you mean by "using role: pageserver in the spans". What I meant is that the hardcoded `pageserver` will now become a new attribute, like...

> Does the `OTEL_SERVICE_NAME` environment variable not already work? Looking at the otel code, it looks like no. > > It does have a way to load attributes from the...

@VladLazar Thank you! Understood what you said above. Our setup doesn't have a sidecar, pageserver just pushes spans directly to OTEL server and we don't control/own the OTEL infrastructure. We...

> The pageserver is a multi-tenant service, so you can serve many PG instances from the same one. This makes sense. What about different pageservers running different shards for the...

Thank you @VladLazar . I think we can close this out. One last question. Internally, how do you annotate "cluster"? By cluster, I mean a Neon cluster, e.g., cluster_1, cluster_2,...