Re: BUG #10013: PostgreSQL 9.4 initdb FATAL: could not write to file "pg_xlog/xlogtemp.3590": No space left on devi

after patched.

pg94(at)db-172-16-3-150-> strace -c initdb
The files belonging to this database system will be owned by user "pg94".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

creating directory /home/pg94/pg_root ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
creating template1 database in /home/pg94/pg_root/base/1 ... LOG: write() in XLogFileInit returned 40960: Success
FATAL: could not write to file "pg_xlog/xlogtemp.832": No space left on device
child process exited with exit code 1
initdb: removing data directory "/home/pg94/pg_root"
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
90.23 0.016045 4011 4 wait4
6.48 0.001153 0 23171 33 stat
2.02 0.000360 0 5866 5339 write
0.62 0.000110 0 1229 21 open
0.21 0.000038 0 1459 read
0.17 0.000030 0 1215 close
0.17 0.000030 1 23 mkdir
0.09 0.000016 0 88 getdents
0.00 0.000000 0 21 fstat
0.00 0.000000 0 30 lstat
0.00 0.000000 0 5 lseek
0.00 0.000000 0 31 mmap
0.00 0.000000 0 9 mprotect
0.00 0.000000 0 14 munmap
0.00 0.000000 0 11 brk
0.00 0.000000 0 16 rt_sigaction
0.00 0.000000 0 5 rt_sigprocmask
0.00 0.000000 0 7 1 access
0.00 0.000000 0 3 socket
0.00 0.000000 0 2 2 connect
0.00 0.000000 0 1 sendto
0.00 0.000000 0 3 recvmsg
0.00 0.000000 0 1 bind
0.00 0.000000 0 1 getsockname
0.00 0.000000 0 4 clone
0.00 0.000000 0 1 execve
0.00 0.000000 0 5 fcntl
0.00 0.000000 0 6 getcwd
0.00 0.000000 0 4 chdir
0.00 0.000000 0 23 rmdir
0.00 0.000000 0 7 unlink
0.00 0.000000 0 4 chmod
0.00 0.000000 0 89 umask
0.00 0.000000 0 1 getrlimit
0.00 0.000000 0 2 geteuid
0.00 0.000000 0 1 statfs
0.00 0.000000 0 1 arch_prctl
0.00 0.000000 0 3 1 futex
0.00 0.000000 0 1 set_tid_address
0.00 0.000000 0 1 set_robust_list
0.00 0.000000 0 2 pipe2
------ ----------- ----------- --------- --------- ----------------
100.00 0.017782 33370 5397 total

--
公益是一辈子的事,I'm Digoal,Just Do It.

At 2014-04-16 19:16:45,"Andres Freund" <andres(at)2ndquadrant(dot)com> wrote:
>On 2014-04-16 14:11:22 +0300, Heikki Linnakangas wrote:
>> On 04/16/2014 01:59 PM, Andres Freund wrote:
>> >On 2014-04-16 13:50:35 +0300, Heikki Linnakangas wrote:
>> >>On 04/16/2014 11:20 AM, digoal(at)126(dot)com wrote:
>> >>>HI,
>> >>> I can reproduce this.
>> >>
>> >>Ok. Can you try with the attached patch applied, please?
>> >
>> >Perhaps this should also support partial writes, akin to
>> >79ce29c734c6a652b2f7193bda537cff0c8eb8c1? I don't find it all that
>> >unreasonble for the OS to refuse 16MB - or even bigger - writes in some
>> >scenarios.
>>
>> The write in XLogFileInit is always 8kB (XLOG_BLCKSZ).
>
>Oh, then disregard that. I just remembered you fixing it for normal wal
>writes...
>
>A strace (or the platform's equivalent) might be interesting. Digoal?
>
>> But yeah, it might
>> make sense to retry. Although I wonder why XLogFileInit would be
>> particularly vulnerable to short writes. I'm afraid if we fix that, next
>> we'll start seeing failures from other writes, to data files.
>
>I personally think we indeed should fix that generally, but that's not a
>small change. We'd probably need some wrappers to make that happen
>sensibly.
>
>Greetings,
>
>Andres Freund
>
>--
> Andres Freund http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services