AW: Re: AW: Re: MySQL and BerkleyDB (fwd)

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Mikheev, Vadim'" <vmikheev(at)SECTORBASE(dot)COM>, "'dom(at)idealx(dot)com'" <dom(at)idealx(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: AW: Re: AW: Re: MySQL and BerkleyDB (fwd)
Date: 2001-01-24 09:19:36
Message-ID: 11C1E6749A55D411A9670001FA6879633681D7@sdexcsrv1.f000.d0188.sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> 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.

1st phase will also need to do all the delayed constraint checks,
and all other work a commit currently does, that could possibly lead
to a transaction abort. The 2nd phase of 2phase commit is not
allowed to return an error, unless of course in case of catastrophe.

> 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.

yup :-) Maybe this could even be raised to the SQL level,
so applications could use this ? I have not seen this elsewhere,
but why actually not ?

Andreas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Frank Joerdens 2001-01-24 09:29:11 Re: Looking for info on Solaris 7 (SPARC) specific considerations
Previous Message Samy Elashmawy 2001-01-24 07:30:18 Re: Re: GreatBridge RPMs (was: Re: question)