MemPostings holds postings list for series ID per label pair. They may be written to out of order. EnsureOrder() must be called once before any reads are done. This allows for quick unordered batch fills on startup.
| 58 | // EnsureOrder() must be called once before any reads are done. This allows for quick |
| 59 | // unordered batch fills on startup. |
| 60 | type MemPostings struct { |
| 61 | mtx sync.RWMutex |
| 62 | |
| 63 | // m holds the postings lists for each label-value pair, indexed first by label name, and then by label value. |
| 64 | // |
| 65 | // mtx must be held when interacting with m (the appropriate one for reading or writing). |
| 66 | // It is safe to retain a reference to a postings list after releasing the lock. |
| 67 | // |
| 68 | // BUG: There's currently a data race in addFor, which might modify the tail of the postings list: |
| 69 | // https://github.com/prometheus/prometheus/issues/15317 |
| 70 | m map[string]map[string][]storage.SeriesRef |
| 71 | |
| 72 | // lvs holds the label values for each label name. |
| 73 | // lvs[name] is essentially an unsorted append-only list of all keys in m[name] |
| 74 | // mtx must be held when interacting with lvs. |
| 75 | // Since it's append-only, it is safe to read the label values slice after releasing the lock. |
| 76 | lvs map[string][]string |
| 77 | |
| 78 | ordered bool |
| 79 | } |
| 80 | |
| 81 | const defaultLabelNamesMapSize = 512 |
| 82 |
nothing calls this directly
no outgoing calls
no test coverage detected