RE: [HACKERS] redolog - for discussion - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: [HACKERS] redolog - for discussion
Date
Msg-id 000801be2a21$4aff8660$2801007e@cadzone.tpf.co.jp
Whole thread Raw
In response to Re: [HACKERS] redolog - for discussion  (Vadim Mikheev <vadim@krs.ru>)
List pgsql-hackers
> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Vadim Mikheev
> Sent: Thursday, December 17, 1998 5:03 PM
> To: Jan Wieck
> Cc: pgsql-hackers@postgreSQL.org
> Subject: Re: [HACKERS] redolog - for discussion
> 
> 
> Jan Wieck wrote:
> > 
> > >
> > > I foresee problems with using _commands_ logging for
> > > recovery/replication -:((
> > >
> ...
> > 
> >     Yepp,  the order in which commands begun is absolutely not of
> >     interest. Locking could already delay the  execution  of  one
> >     command  until  another  one  started  later has finished and
> >     released the lock.  It's a classic race condition.
> > 
> >     Thus, my plan was to log the queries just before the call  to
> >     CommitTransactionCommand()  in  tcop. This has the advantage,
> 
> Oh, I see - you right!
>

If   image level logging is used,probably it's OK.
But if query(command) level logging is used ???

If   the isolation level of all transactions is SERIARIZABLE,it's probably 
OK because they are serializable  order by the time when they are 
committed.
But if there are transactions whose isolation level is READ COMMITTED,
they are not serializable.
So commands must be issued according to the original order when they 
were issued ?

If   the same mechanism of locking is used at recovery time,the order 
of locks caused by commands(rerun) will be same ?????
I'm not confident.   
Thanks.

Hiroshi inoue
Inoue@tpf.co.jp


pgsql-hackers by date:

Previous
From: jwieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] CVS log for a specific tag
Next
From: Keith Parks
Date:
Subject: Re: [HACKERS] CURRENT: crash in select_view regression test...