Re: [HACKERS] fsynch of pg_log write..

At 10:18 AM 6/25/99 +0200, Zeugswetter Andreas IZ5 wrote:
> Vadim wrote:
>> Right way is just set some flag in WriteBuffer()/WriteNoReleaseBuffer()
>> and don't do
>>
>> FlushBufferPool
>> TransactionIdCommit
>> FlushBufferPool
>>
>> at all when this flag is not setted.

>While this is even much better for select only transactions
>it will still do the second flush for writers.
>This flush is not needed for those, that are only interested
>in consistency, and don't care if the last transaction before
>system/backend crash is lost.
>It can actually really only be the very last transaction reported
>ok to any client, that is rolled back, since all other xactions
>will be flushed by this same first FlushBufferPool
>(since BufferSync currently flushes all dirty Pages).
>So IMHO a switch to avoid the second FlushBufferPool
>would still be useful, even with this suggested fix.

That was what I was wondering when I saw Vadim's post,
but seeing as yesterday was the first time I'd ever
dug into the Postgres source, I didn't really feel I
was on solid ground.

Obviously, skipping the entire flush/log id/flush cycle
for read only selects is the RIGHT thing to do. As is
ensuring that flushing the buffers only flushes those
modified by the transaction in question rather than
flushing the world...

For now, though, I don't mind living with my simple
hack if indeed it simply means I risk losing a transaction
during a crash. Or, actually, have simply increased that risk
(the sequence flush/log id/CRASH is possible, after all).

I'm a lot more comfortable with this than with the potential
damage done during a crash when fsync'ing both log file and
data is disabled, when the log can then be written by the
system followed by a crash before the data tuples make it
to disk.

- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
Nature photos, on-line guides, and other goodies at
http://donb.photo.net