Re: Proposal for CSN based snapshots
От | Greg Stark |
---|---|
Тема | Re: Proposal for CSN based snapshots |
Дата | |
Msg-id | CAM-w4HNd7scGsvX_e+sxbPB1Y33MHp9D=go69Y4V37KhjE7heg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal for CSN based snapshots (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: Proposal for CSN based snapshots
|
Список | pgsql-hackers |
On Fri, May 30, 2014 at 3:59 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > If transaction A commits synchronously with commit LSN 1, and transaction B > commits asynchronously with commit LSN 2, B cannot become visible before A. > And we cannot acknowledge B as committed to the client until it's visible to > other transactions. That means that B will have to wait for A's commit > record to be flushed to disk, before it can return, even though it was an > asynchronous commit. I thought that's what happens now. What's more of a concern is synchronousl replication. We currently have a hack that makes transactions committed locally invisible to other transactions even though they've committed and synced to disk until the slave responds that it's received the transaction. (I think this is bogus personally, it just shifts the failure modes around. If we wanted to do it properly we would have to do two-phase commit.) I guess it still works because we don't support having synchronous replication for just some transactions and not others. It would be nice to support that but I think it would mean making it work like local synchronous commit. It would only affect how long the commit blocks, not when other transactions see the committed data. -- greg
В списке pgsql-hackers по дате отправления: