From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
---|---|
To: | Don Baccus <dhogaza(at)pacifier(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] fsynch of pg_log write.. |
Date: | 1999-06-25 02:51:47 |
Message-ID: | 3772EEC3.4F306F77@krs.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Don Baccus wrote:
>
> FlushBufferPool /* flush and fsync the data blocks */
> TransactionIdCommit /* log the fact that the transaction's done */
> FlushBufferPool /* flush and fsync pg_log and whatever else
> has changed during this brief period of time */
>
> I just added a couple of lines of code that saves
> disableFsync and sets it true before the second call
> to FlushBufferPool, restoring it to its original state
> afterwards.
...
> So...does it sound like I'm doing the right thing?
It's bad in the case of concurrent writes, because of
second FlushBufferPool "flushes whatever else has changed during
this brief period of time".
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.
I'll do it for 6.5.1 if no one else...
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Edmund Mergl | 1999-06-25 03:45:48 | Re: [HACKERS] Perl 5 Interface on 6.5 and lo_creat/lo_open problem |
Previous Message | Vadim Mikheev | 1999-06-25 01:18:59 | Re: [HACKERS] The dangers of "-F" |