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  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список 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 по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: recovery testing for beta
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: SP-GiST bug.