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 | 20001111230050.Y11449@fw.wintelcom.net обсуждение исходный текст |
Ответ на | Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
* Tom Lane <tgl@sss.pgh.pa.us> [001111 12:06] wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> I have to agree with Alfred here: this does not sound like a feature, > >> it sounds like a horrid hack. You're giving up *all* consistency > >> guarantees for a performance gain that is really going to be pretty > >> minimal in the WAL context. > > > It does not give up consistency. The db is still consistent, it is just > > consistent from a few seconds ago, rather than commit time. > > No, it isn't consistent. Without the fsync you don't know what order > the kernel will choose to plop down WAL log blocks in; you could end up > with a corrupt log. (Actually, perhaps that could be worked around if > the log blocks are suitably marked so that you can tell where the last > sequentially valid one is. I haven't looked at the log structure in > any detail...) This could be fixed by using O_FSYNC on the open call for the WAL data files on *BSD, i'm not sure of the sysV equivelant, but I know it exists. -- -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 по дате отправления: