Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
| От | Tom Lane |
|---|---|
| Тема | Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c) |
| Дата | |
| Msg-id | 28706.973972967@sss.pgh.pa.us обсуждение |
| Ответ на | Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c) (Bruce Momjian <pgman@candle.pha.pa.us>) |
| Ответы |
Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c
xlog.c)
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 |
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...)
regards, tom lane
В списке pgsql-hackers по дате отправления: