Re: Proposal for CSN based snapshots
От | Heikki Linnakangas |
---|---|
Тема | Re: Proposal for CSN based snapshots |
Дата | |
Msg-id | 5388A063.5000209@vmware.com обсуждение исходный текст |
Ответ на | Re: Proposal for CSN based snapshots (Greg Stark <stark@mit.edu>) |
Ответы |
Re: Proposal for CSN based snapshots
|
Список | pgsql-hackers |
On 05/30/2014 06:09 PM, Greg Stark wrote: > 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.) Yeah. To recap, the failure mode is that if the master crashes and restarts, the transaction becomes visible in the master even though it was never replicated. > 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. Actually, we do support that, see synchronous_commit=local. - Heikki
В списке pgsql-hackers по дате отправления: