Re: 9.4 regression

On Thu, Aug 8, 2013 at 5:25 PM, Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> wrote:
> On Thu, Aug 8, 2013 at 5:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> writes:
>>> On Thu, Aug 8, 2013 at 4:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> Does your test program use all the same writing options that the real
>>>> WAL writes do (like O_DIRECT)?
>>
>>> I believe so.
>>
>>>> From xlog.c:
>>
>>> /* do not use get_sync_bit() here --- want to fsync only at end of fill */
>>> fd = BasicOpenFile(tmppath, O_RDWR | O_CREAT | O_EXCL | PG_BINARY,
>>> S_IRUSR | S_IWUSR);
>>
>>> and from the test program:
>>
>>> fd = open(filename, O_CREAT | O_EXCL | O_WRONLY, 0600);
>>
>> Maybe I misunderstood, but I thought the performance complaint had to do
>> with the actual writes of WAL data, not with the pre-fill. That is, you
>> should not just be measuring how long the pre-fill takes, but what is the
>> speed of real writes to the file later on (which will be using
>> get_sync_bit, for various values of the sync settings).
>
> Ah, no, I misunderstood your question.
> I'm fairly certain the test program doesn't open up files with any
> sort of sync. bit set.
> I'll have to see what PostgreSQL is using, exactly, and get back to you.

My reading of xlog.c seems to indicate that if the sync mode is
fdatasync, then the file is not opened with any special sync bit, but
that an fdatasync occurs at the end. That is also what the test
program does.

--
Jon