AW: [HACKERS] TODO item - Mailing list pgsql-hackers

From Zeugswetter Andreas SB
Subject AW: [HACKERS] TODO item
Date
Msg-id 219F68D65015D011A8E000006F8590C603FDC245@sdexcsrv1.f000.d0188.sd.spardat.at
Whole thread Raw
List pgsql-hackers
>     /*
>      * If no one shared buffer was changed by this transaction then
>      * we don't flush shared buffers and don't record commit status.
>      */
>     if (SharedBufferChanged)
>     {
>         FlushBufferPool();
>         sync();
>         if (leak)
>             ResetBufferPool();
> 
>         /*
>          *    have the transaction access methods 
> record the status
>          *    of this transaction id in the pg_log relation.
>          */
>         TransactionIdCommit(xid);
> 
>         /*
>          *    Now write the log info to the disk too.
>          */
>         leak = BufferPoolCheckLeak();
>         FlushBufferPool();

Would it be a win if this second call to FlushBufferPool would only fsync
pg_log ?
Since if I read correctly, this call will also flush IO from other sessions.

If I remember correctly I did a test by commenting the second
FlushBufferPool call,
but that resulted in some regression failures.
This call would actually not be needed for DB consistency issues (ACID). 
It is only needed for Client/Server consistency 
(client got commit ok, but server does rollback on crash).

>         sync();
>     }


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] TODO item
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] minor bug...