Hi, On Mon, Sep 16, 2024 at 2:25 AM shveta malik <shveta.ma...@gmail.com> wrote:
> > > > > > If we don't do something similar, then aren't there chances that we > > > keep on waiting on the wrong lsn[mode] for the case when mode = > > > SYNC_REP_WAIT_APPLY while sync-rep-wait infrastructure is updating > > > different mode's lsn. Is my understanding correct? > > > Let me take a deeper look at this, I think you're right though. > > I agree. So even if the mode is SYNC_REP_WAIT_WRITE (lower one) or > SYNC_REP_WAIT_APPLY (higher one), we need to wait for > lsn[SYNC_REP_WAIT_FLUSH]. > I'm not sure if I agree with that. I think the sychronous_commit mode should be a good enough proxy for what the user wants from a durability perspective for their application. For an application writing to the database, if they've set mode as SYNC_REP_WAIT_WRITE as fine being when a commit is treated as durable, why do we need to be concerned with overriding that to SYNC_REP_WAIT_FLUSH? Similarly, if a user has mode set to SYNC_REP_WAIT_APPLY, to me it's even more confusing that there can be scenarios where the application wouldn't see the data as committed nor would subsequent reads but a logical consumer would be able to. The database should be treated as the source of truth and I don't think logical consumers should be ever ahead of what the database is treating as committed. Thanks, -- John Hsu - Amazon Web Services
