On Fri, 13 Aug 2004, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>>> Tom Lane wrote:
>>>> Who exactly signed onto this as a good idea? It sure doesn't square
>>>> with my ideas of an ACID database. Committed means committed, not
>>>> "maybe if you're lucky committed".
>>
>>> True but we support fsync. Certainly it would be more useful than
>>> fsync, and it might allow us to remove fsync.
>>
>> How so? fsync off is for I-don't-care-about-this-data-at-all cases
>> (primarily development, though loading already-archived data can
>> qualify too). I'm not seeing a use-case for "I care about this data,
>> but only once it's more than N seconds old". It certainly does not
>> replace "just go as fast as you can", which is what fsync off means.
>>
>>> No one has to sign TODO items, BTW. They are added and removed as
>>> requested.
>>
>> [ shrug... ] So if I request removal of this item, it will go away
>> again? It hasn't reached the age needed to guarantee commit ;-)
>
> Many databases offer this feature. The submitter asked for it, and I
> think it is a good idea. For cases where you are running an in-house
> app, you can tell your employees to re-key the stuff they did just
> before the crash. It doesn't work for web apps and stuff, but for
> smaller cases it is fine.
>
> With Informix, the logic used by most customers I dealt with was that
> unbuffered logging was too slow and they were willing to do a few rekeys
> for the performance gain.
I tend to agree with Tom that this is a bad idea, but ... if we do
foolishly implement this, can it be a disfeature that is only available
via a special configure flag on compile, that creates a special GUC
variable that defaults to the standard behaviour?
Basically, if you desire to risk cutting off your left hand for the sake
of speed, put them through a couple of hoops to get there first ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
