this is an area I hadn't thoroughly considered before. my initial thought was simply to align with the &mut mutability behavior of standard library collections like

Vec

. when iterating, write references are disallowed because a write might cause `Vec`'s memory layout to change, potentially invalidating existing

&

references. I suppose I need to think more deeply about this part, whether it should be considered as a different context on the xor semantics between

&mut

and

&

in the SSI transaction 🤔.

if i understand correctly, in the

DB

operations, it's allowed to

scan()

in the mid while getting

write()

operations, and the iterator is able to return the data from the later

write()

operation. hmm...

My thinking here was that it would be nice to be able to do something like scan -> test and set one record at a time from the iterator stream (increment a counter for example) From the code, it seems

WriteBatch

has clone, so some kind of copy-on-write for the WriteBatch to the DbIterator might make it possible to achieve this feature, but I'm not sure if that violates some other invariants here.

@almog great talk btw

hi, @criccomini nice to meet you.

Hi!

Found an interesting paper around scaleable ultra-accurate clock synchronization in software. Could be possibly leveraged in case slateDB becomes distributed. https://dl.acm.org/doi/pdf/10.1145/3718958.3750502

I dug into the timeout on our nightly last night. I can't reproduce it after 1000s of runs in a loop both with and without max CPU saturation. I'm going to chalk it up to annoying GH runners. I'll put a PR up this weekend to move these tests over to WarpBuild, which seems a bit more steady.

Hi all. Been playing around with with a quick Foyer - SlateDB - Garage type of thing on my homelab mesh and has been working pretty well for all sorts of things I throw at. Hopping here to keep tabs. Good stuff ❤️

@Pierre you gonna be up for testing out

main

this week? Starting to gear up for 0.9.0

More eyes the better

@criccomini before we cut 0.9.0 I want to take a look at https://github.com/slatedb/slatedb/issues/958 -- seems like a really bad bug if true, though it could also be AI generated nonsense. I was running some memory utilization tests and saw way more memory than expected, turns out we were replaying WALs that were already compacted

Yes, for sure!

@criccomini Is this one going to be included? 🙏 https://github.com/slatedb/slatedb/issues/604

@Pierre It depends on progress from @Sujeet that is still ongoing. I'm honestly not sure. If not, we can try and cut a 0.9.1 when we get it in.

The compactor persistence is progressing (which is required for 604), but we aren't yet writing it.

Oh no 😆

Haha yea.. not ideal, but I want to make ure the compactor data models are really thought out

Since it's persistence stuff we're going to need to live with for a while

But let's see how it goes 🤞 Sujeet is very fast.. at this point it's just reviews that're slowing him down

For sure, great work!!

On my way to migrate that postgres table to ZeroFS 😄 https://cdn.discordapp.com/attachments/1232385660946616433/1432802394768408786/image.png?ex=690260b7&is=69010f37&hm=18de584b5a331e2da30a79ae0dadbae97eebfbb422bb7fe2f910a62fda872102&

🤔 which PG table is this?

Bunch of 2025 certificates for merklemap.com

Ahh 😄

lol

Looks like object_store 0.13 is coming in Nov: https://github.com/apache/arrow-rs-object-store/issues/367#issuecomment-3458047275

Man, Rust is really being a pain in the ass today... 😵‍💫

All, would love to have some eyes/feedback on this: https://github.com/slatedb/slatedb/pull/965 cc @Pierre