Re: Re: AW: Re: MySQL and BerkleyDB (fwd)
От | Bruce Momjian |
---|---|
Тема | Re: Re: AW: Re: MySQL and BerkleyDB (fwd) |
Дата | |
Msg-id | 200101250336.WAA00871@candle.pha.pa.us обсуждение исходный текст |
Ответ на | RE: Re: AW: Re: MySQL and BerkleyDB (fwd) ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>) |
Список | pgsql-hackers |
Added to TODO.detail/replication. [ Charset ISO-8859-1 unsupported, converting... ] > > I had thought that the pre-commit information could be stored in an > > auxiliary table by the middleware program ; we would then have > > to re-implement some sort of higher-level WAL (I thought of the list > > of the commands performed in the current transaction, with a sequence > > number for each of them that would guarantee correct ordering between > > concurrent transactions in case of a REDO). But I fear I am missing > > This wouldn't work for READ COMMITTED isolation level. > But why do you want to log commands into WAL where each modification > is already logged in, hm, correct order? > Well, it has sense if you're looking for async replication but > you need not in two-phase commit for this and should aware about > problems with READ COMMITTED isolevel. > > Back to two-phase commit - it's easiest part of work required for > distributed transaction processing. > Currently we place single commit record to log and transaction is > committed when this record (and so all other transaction records) > is on disk. > Two-phase commit: > > 1. For 1st phase we'll place into log "prepared-to-commit" record > and this phase will be accomplished after record is flushed on disk. > At this point transaction may be committed at any time because of > all its modifications are logged. But it still may be rolled back > if this phase failed on other sites of distributed system. > > 2. When all sites are prepared to commit we'll place "committed" > record into log. No need to flush it because of in the event of > crash for all "prepared" transactions recoverer will have to > communicate other sites to know their statuses anyway. > > That's all! It is really hard to implement distributed lock- and > communication- managers but there is no problem with logging two > records instead of one. Period. > > Vadim > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: