Re: pgsql-server: Add: > > * Allow buffered WAL writes

On Sat, 14 Aug 2004, Bruce Momjian wrote:

> Marc G. Fournier wrote:
>> On Sat, 14 Aug 2004, Bruce Momjian wrote:
>>
>>> Marc G. Fournier wrote:
>>>> On Sat, 14 Aug 2004, Tom Lane wrote:
>>>>
>>>>> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>>>>>> Many databases offer this feature. The submitter asked for it,
>>>>>
>>>>> Actually he didn't --- AFAICS you misinterpreted the thread completely.
>>>>> The original suggestion was that we might be able to exploit a
>>>>> transactional filesystem to improve performance *without* sacrificing
>>>>> any correctness guarantees. Delayed fsync has nothing to do with that.
>>>>>
>>>>> (I'm dubious whether there's any performance improvement to be had that
>>>>> would be worth the code uglification involved, since we're surely not
>>>>> going to *require* a transactional filesystem and so two very different
>>>>> code paths seem to be needed. But it's at least something to think about.)
>>>>
>>>> Just to expand on the 'dubiousness' ... remember awhile back when I worked
>>>> through the 'no-WAL' version of PostgreSQL to test loading a database with
>>>> WAL disabled? The performance improvements on loading a database weren't
>>>> enough, I seem to recall, to warrant getting rid of WAL altogether ... so
>>>> I can't see 'delayed WAL' being faster then 'no WAL' ...
>>>
>>> Uh, you mean fsync isn't a performance hit as it once was?
>>
>> No, I mean that writing WAL doesn't appear to be a performance hit ...
>> removing WAL writing and doing a large db load, the load is a bit faster,
>> but not as big as one would hope ...
>
> OK. My idea is to remove fsync (poorly named) and add a new parameter
> called transaction_loss. It would specify the number of seconds or
> milliseconds before an abrupt server restart that you were willing to
> lose transactions. The default would be zero (no loss), and we can
> support -1 for the same as fsync off. Positive values would delay WAL
> write/fsync for that many seconds/milliseconds.

'k, right now we have a seperate variable for wal_fsync vs regular fsync
... are you looking at merging them into one? Or leaving them as being
treated seperately?

One question, more directed to Tom here ... since they are seperate right
now, if WAL is fsync, and "regular writing" is no-fsync, doesn't that
potentially open us up to some *serious* problems? WAL sees the
transaction as complete, but the write for the rest of the system hasn't
happened yet?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664