Re: COMMIT NOWAIT Performance Option
От | Tom Lane |
---|---|
Тема | Re: COMMIT NOWAIT Performance Option |
Дата | |
Msg-id | 19370.1172609772@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: COMMIT NOWAIT Performance Option ("Joshua D. Drake" <jd@commandprompt.com>) |
Ответы |
Re: COMMIT NOWAIT Performance Option
Re: COMMIT NOWAIT Performance Option |
Список | pgsql-hackers |
"Joshua D. Drake" <jd@commandprompt.com> writes: > Josh Berkus wrote: >> It seriously narrows down the problem space to know that PostgreSQL does *not* >> allow data loss if it's physically possible to prevent it. > But we do don't we? fsync = off, full_page_writes = off? One of the things that's really attractive about the proposed mode is that it does *not* create a risk of data corruption (assuming that Simon's analyzed it correctly --- I think the clog code in particular needs a look). What you risk is that when the database comes back up, its state may reflect an instant up to X seconds before the time of the crash, rather than exactly the crash time. It seems to me that that's way better than fsync = off, which allows unlimited corruption. I agree that we ought to look at some performance numbers before accepting the patch, but I think Josh's argument that this opens us up to major corruption problems is probably wrong. The question is whether your application can tolerate loss of "very recent" transactions, and I think there are plenty where it can. regards, tom lane
В списке pgsql-hackers по дате отправления: