On Tue, 10 Feb 2015, Gregory Farnum wrote: > On Tue, Feb 10, 2015 at 10:26 AM, Sage Weil <sw...@redhat.com> wrote: > > On Tue, 10 Feb 2015, Somnath Roy wrote: > >> Thanks Sam ! > >> So, is it safe to do ordering if in a transaction *no* > >> remove/truncate/create/add call ? > >> For example, do we need to preserve ordering in case of the below > >> transaction ? > >> It will be helpful if you can give some insight in what scenario > >> preserving order is *must*. > > > > If I'm not mistaken teh only time ordering would matter at all in an > > transaction is when the same key is updated twice, right? The whole thing > > is committed atomically. If there *are* dups, then the order there > > obviously should be preserved. > > > > Maybe a first pass would be add an assert or something that there are no > > dup keys and see if anything every falls out of that... hopefully there > > are none! > > I'm pretty sure some of the transaction analysis discussions people > have had say that we do double-updates at times. IIRC it might have > been the pglog head getting set twice in most transactions?
Oh yeah, could be. There was the snapset xattr update, but that was resetting it to an existing value (not the same value inside the same txn). I forget if there were others. sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html