Thank you. Data can't be corrupted in case crash because of WAL replay (since completed checkpoint). Physical records are used to restore probably corrupted pages in persistent store (we overwrite so called 'grey zone' - pages we don't know for sure if they have been written).
Only one effect is unwritten one or several last transactions. It is not the same with corrupted data. пт, 16 февр. 2018 г. в 19:19, Vladimir Ozerov <voze...@gridgain.com>: > Log only mode is not safe - data might be corrupted in case of system > crash. Oracle - fsync, Postgres - fsync, SQL Server - fsync, Cassandra - > similar to our “background”. > > пт, 16 февр. 2018 г. в 19:11, Dmitry Pavlov <dpavlov....@gmail.com>: > > > Hi Vladimir, > > > > What you saying is defenetely make sence. > > > > In the same time LOG_ONLY is also safe mode, user will be able to restore > > system after crash. If it is not true, we should create critical ticket > and > > fix it. > > > > Do you know other databases defaults, such as Cassandra, Oracle, Postgre? > > > > Sincerely, > > Dmitriy Pavlov > > > > пт, 16 февр. 2018 г. в 18:41, Vladimir Ozerov <voze...@gridgain.com>: > > > > > Igniters, > > > > > > Sorry for pouring oil on the flames, but from database perspective > moving > > > from FSYNC to non-FSYNC mode appears to be a mistake. When you work > with > > > database, your main expectation is that it will save your data. All > > > production database vendor make sure that you are safe, not that you > are > > > fast. Moreover, some vendors even prevent you from being in unsafe mode > > > (e.g. you cannot disable fsync in SQL Server at all). > > > > > > If we continue going in this direction, we will end up with a product, > > > which is unsafe out of the box and require tons of documentation to > > > understand how to make it safe. Definitely not the right message to the > > > market. This is like a car without brakes - would you like to drive it? > > If > > > this is Need For Speed game and you have unlimited lives (in-memory > cache > > > with backing store), then yes. If this is a real life with > (persistence) > > - > > > then no. > > > > > > On Fri, Feb 16, 2018 at 5:20 PM, Dmitriy Setrakyan < > > dsetrak...@apache.org> > > > wrote: > > > > > > > Well, I cannot say that I like the name LOG_ONLY, but I would vote to > > > keep > > > > it for now, given that it is already documented in many places, > blogs, > > > and > > > > examples. > > > > > > > > D. > > > > > > > > On Fri, Feb 16, 2018 at 8:13 AM, Ivan Rakov <ivan.glu...@gmail.com> > > > wrote: > > > > > > > > > Looks like it's an Ignite term - I've never heard of it outside > > Ignite > > > > > scope. > > > > > > > > > > Though, renaming existing enum value requires keeping old as > > > deprecated. > > > > > DEFAULT is confusing enough to pay this price. > > > > > As for LOG_ONLY, I think we can keep it as long as it has good and > > > > > definitive javadoc. > > > > > > > > > > Best Regards, > > > > > Ivan Rakov > > > > > > > > > > > > > > > On 16.02.2018 17:07, Dmitriy Setrakyan wrote: > > > > > > > > > >> Igniters, just to clarify, does the term LOG_ONLY mean anything in > > the > > > > >> industry or is this just an Ignite term? > > > > >> > > > > >> D. > > > > >> > > > > >> On Fri, Feb 16, 2018 at 8:03 AM, Anton Vinogradov < > > > > >> avinogra...@gridgain.com> > > > > >> wrote: > > > > >> > > > > >> Log only mode: flushes application buffers. > > > > >>> So, in synced mode without fsync guarantee. That's why I propose > to > > > > >>> rename > > > > >>> it as SYNC. > > > > >>> > > > > >>> On Fri, Feb 16, 2018 at 4:49 PM, Ilya Lantukh < > > ilant...@gridgain.com > > > > > > > > >>> wrote: > > > > >>> > > > > >>> I am OK with either FSYNC or STRICT variant. > > > > >>>> > > > > >>>> LOG_ONLY name means "log without fsync". > > > > >>>> > > > > >>>> On Fri, Feb 16, 2018 at 4:05 PM, Dmitriy Setrakyan < > > > > >>>> > > > > >>> dsetrak...@apache.org> > > > > >>> > > > > >>>> wrote: > > > > >>>> > > > > >>>> On Fri, Feb 16, 2018 at 7:02 AM, Ivan Rakov < > > ivan.glu...@gmail.com> > > > > >>>>> > > > > >>>> wrote: > > > > >>>> > > > > >>>>> Why create a new term to define something that has already been > > > > >>>>>> > > > > >>>>> defined? > > > > >>>> > > > > >>>>> That makes sense. I'm ok with FSYNC. > > > > >>>>>> Anton, I don't understand why we should rename LOG_ONLY to > SYNC. > > > We > > > > >>>>>> started this discussion with bad naming of DEFAULT, but this > has > > > > >>>>>> > > > > >>>>> nothing > > > > >>>> > > > > >>>>> to > > > > >>>>> > > > > >>>>>> do with LOG_ONLY (even though it may be scientific - but SYNC > > > sounds > > > > >>>>>> scientific as well). > > > > >>>>>> > > > > >>>>>> I agree with Ivan, we should not go wild with renaming. > > However, I > > > > >>>>> > > > > >>>> would > > > > >>> > > > > >>>> like to find out what is the meaning behind the LOG_ONLY name. > Can > > > > >>>>> > > > > >>>> someone > > > > >>>> > > > > >>>>> explain? > > > > >>>>> > > > > >>>>> D. > > > > >>>>> > > > > >>>>> > > > > >>>> > > > > >>>> -- > > > > >>>> Best regards, > > > > >>>> Ilya > > > > >>>> > > > > >>>> > > > > > > > > > > > > > > >
