Re: fallocate / posix_fallocate for new WAL file creation (etc...)
От | Jon Nelson |
---|---|
Тема | Re: fallocate / posix_fallocate for new WAL file creation (etc...) |
Дата | |
Msg-id | CAKuK5J2QK0M1ON=DiB00Yp4_0B__Ks1J=axAYeJYBiA55FUqbg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: fallocate / posix_fallocate for new WAL file creation (etc...) (Greg Smith <greg@2ndQuadrant.com>) |
Список | pgsql-hackers |
On Sun, Jun 30, 2013 at 5:55 PM, Greg Smith <greg@2ndquadrant.com> wrote: > > > pwrite(4, "\0", 1, 16769023) = 1 > pwrite(4, "\0", 1, 16773119) = 1 > pwrite(4, "\0", 1, 16777215) = 1 > > That's glibc helpfully converting your call to posix_fallocate into small > writes, because the OS doesn't provide a better way in that kernel. It's > not hard to imagine this being slower than what the WAL code is doing right > now. I'm not worried about correctness issues anymore, but my gut paranoia > about this not working as expected on older systems was justified. Everyone > who thought I was just whining owes me a cookie. I had noted in the very early part of the thread that glibc emulates posix_fallocate when the (Linux-specific) 'fallocate' systemcall fails. In this case, it's writing 4 bytes of zeros and then essentially seeking forward 4092 (4096-4) bytes. This prevents files with holes in them because the holes have to be at least 4kiB in size, if I recall properly. It's *not* writing out 16MiB in 4 byte increments. -- Jon
В списке pgsql-hackers по дате отправления: