AW: [HACKERS] TODO item

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Tatsuo Ishii'" <t-ishii(at)sra(dot)co(dot)jp>
Cc: "'tgl(at)sss(dot)pgh(dot)pa(dot)us'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'pgsql-hackers(at)postgreSQL(dot)org'" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: AW: [HACKERS] TODO item
Date: 2000-02-09 15:50:24
Message-ID: 219F68D65015D011A8E000006F8590C603FDC245@sdexcsrv1.f000.d0188.sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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();
> }

Browse pgsql-hackers by date

  From Date Subject
Next Message Don Baccus 2000-02-09 15:54:27 Re: [HACKERS] backend startup
Previous Message Tatsuo Ishii 2000-02-09 15:09:25 Re: [HACKERS] TODO item