RE: [HACKERS] redolog - for discussion
От | Hiroshi Inoue |
---|---|
Тема | RE: [HACKERS] redolog - for discussion |
Дата | |
Msg-id | 000801be2a21$4aff8660$2801007e@cadzone.tpf.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] redolog - for discussion (Vadim Mikheev <vadim@krs.ru>) |
Список | 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 по дате отправления: