Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)

Поиск
Список
Период
Сортировка
От Alfred Perlstein
Тема Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Дата
Msg-id 20001110191925.K11449@fw.wintelcom.net
обсуждение исходный текст
Ответ на RE: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Ответы Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Список pgsql-hackers
* Tatsuo Ishii <t-ishii@sra.co.jp> [001110 18:42] wrote:
> > 
> > Yes, though we can change this. We also can implement now
> > feature that Bruce wanted so long and so much -:) -
> > fsync log not on each commit but each ~ 5sec, if
> > losing some recent commits is acceptable.
> 
> Sounds great.

Not really, I thought an ack on a commit would mean that the data
is actually in stable storage, breaking that would be pretty bad
no?  Or are you only talking about when someone is running with
async Postgresql?

Although this doesn't have an effect on my current application,
when running Postgresql with sync commits and WAL can one expect
the old behavior, ie. success only after data and meta data (log)
are written?

Another question I had was what would the effect of a mid-fsync
crash have on a system using WAL, let's say someone yanks the
power while the OS in the midst of fsync, will all be ok?

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: RE: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Следующее
От: Philip Warner
Дата:
Сообщение: Re: Unhappy thoughts about pg_dump and objects inherited from template1