Thread: Re: [HACKERS] fsynch of pg_log write..

    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.

Andreas

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.

I didn't object this.

Vadim