Re: Transaction Guarantee, updated version
От | Tom Lane |
---|---|
Тема | Re: Transaction Guarantee, updated version |
Дата | |
Msg-id | 21665.1182522158@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Transaction Guarantee, updated version ("Simon Riggs" <simon@2ndquadrant.com>) |
Ответы |
Re: Transaction Guarantee, updated version
|
Список | pgsql-patches |
"Simon Riggs" <simon@2ndquadrant.com> writes: > On Thu, 2007-06-21 at 16:05 -0400, Tom Lane wrote: >> Can we fix it to be a read test instead of a write test, that is, if >> we know WAL has been flushed through the target LSN, it's safe to set >> the hint bit, else not? > Yes, that's roughly how it worked in v1. > The various possible strategies for handling hint bits were: > 1. flush WAL to current insert pointer - very heavy perf hit > 2. defer setting the hint bits at all, if the written transactions are > recently written. To do this we need a cache of recently written > deferred commit Xids. > 3. flush WAL up to the LSN of the Xid, if it is a deferred commit. To do > this we need a cache of recently written deferred commit Xids. I think you misunderstood me: 4. If WAL has not been flushed far enough to be certain that the target transaction's commit is synced, then defer setting the hint bit. This does not require any new per-transaction state, we can just measure it on the basis of the lsn associated with the clog page that the transaction's state is in. Compared to #2, this gets rid of complexity of bookkeeping at the cost of not being able to set hint bits as soon as we otherwise could. I think both #1 and #3 would lose most of the advantage of deferred commit, as it is not at all uncommon for a transaction's effects to be examined by the following transaction, so you'd be flushing WAL immediately just to set hint bits. regards, tom lane
В списке pgsql-patches по дате отправления: