Re: BufFileWrite across MAX_PHYSICAL_FILESIZE boundary - Mailing list pgsql-hackers

From Tom Lane
Subject Re: BufFileWrite across MAX_PHYSICAL_FILESIZE boundary
Date
Msg-id 19107.1178574338@sss.pgh.pa.us
Whole thread Raw
In response to BufFileWrite across MAX_PHYSICAL_FILESIZE boundary  ("Kurt Harriman" <kharriman@greenplum.com>)
Responses Re: BufFileWrite across MAX_PHYSICAL_FILESIZE boundary  (Bruce Momjian <bruce@momjian.us>)
Re: BufFileWrite across MAX_PHYSICAL_FILESIZE boundary  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"Kurt Harriman" <kharriman@greenplum.com> writes:
> Just noticed buffile.c:292 doesn't look quite right where
> BufFileDumpBuffer calls FileWrite:
>      bytestowrite = FileWrite(thisfile, file->buffer, bytestowrite);
> It looks as though it would write the same data each time the
> loop is iterated.  Would this be better?
>      bytestowrite = FileWrite(thisfile, file->buffer + wpos, bytestowrite);

Yeah, I think you're right.  We've probably not seen this because in
most usages the buffer is always block-aligned, but it looks possible
for tuplestore.c to get out of alignment if its concurrent write/read
feature is exercised just so.  Do you want to try demonstrating the bug
with a smaller-than-normal setting of MAX_PHYSICAL_FILESIZE?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: pg_type
Next
From: Tom Lane
Date:
Subject: Re: pg_type