Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> I thought about that too. I admit I am not sure if this really works
>> portably; however I don't want to add a palloc() to that routine.
> It should work, AFAIK, but unaligned memcpy()s and write()s can be a
> significant
Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
I have some comments about the double-buffering:
Since posting this patch I have realized that this implementation is
bogus. I'm now playing with WAL-logging hint bits though.
Yeah, the torn page + hint bit updates problem is the tough questi
ITAGAKI Takahiro wrote:
> I have some comments about the double-buffering:
Since posting this patch I have realized that this implementation is
bogus. I'm now playing with WAL-logging hint bits though. As to your
questions:
> - Are there any performance degradation because of addtional memcpy?
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> I'm trying to see if it makes sense to do the double-buffering of page
> writes before going further ahead with CRC checking. I came up with the
> attached patch; it does the double-buffering inconditionally, because as
> it was said, it allows releasi
Hi,
I'm trying to see if it makes sense to do the double-buffering of page
writes before going further ahead with CRC checking. I came up with the
attached patch; it does the double-buffering inconditionally, because as
it was said, it allows releasing the io_in_progress lock (and resetting
BM_IO
