| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Worries about delayed-commit semantics |
| Date: | 2007-06-22 15:01:02 |
| Message-ID: | 22334.1182524462@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Joshua D. Drake wrote:
>>>> Hm, another possibility: "synchronous_commit = off"
>>>> Ooo, I like that. Any other takers?
>>> Yea, I like that too but I am now realizing that we are not really
>>> deferring or delaying the "COMMIT" command but rather the recovery of
>>> the commit. GUC as full_commit_recovery?
>>
>> recovery is a bad word I think. It is related too closely to failure.
> commit_stability? reliable_commit?
What's wrong with synchronous_commit? It's accurate and simple.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oleg Bartunov | 2007-06-22 15:02:37 | Re: tsearch in core patch |
| Previous Message | Simon Riggs | 2007-06-22 14:57:51 | Re: Worries about delayed-commit semantics |