Hi Konstantin,

I recently updated my dev box to r292962. After doing this I attempted to set 
up PostgreSQL 9.4. When I ran initdb the last phase hung. Using procstat -kk I 
found it appeared to be stuck in a loop inside a posix_fadvise syscall. I could 
not ^C or ^Z the initdb process. I could kill it but a subsequent attempt to rm 
-rf the /usr/local/pgsql/data directory also got stuck and was unkillable by 
any means. Rebooting allowed me to remove the directory but the initdb process 
still hung when I re-ran it.

I tried PostgreSQL 9.3 with similar results.

Looking at the source code for initdb I found that it calls posix_fadvise like 

      * We do what pg_flush_data() would do in the backend: prefer to use
      * sync_file_range, but fall back to posix_fadvise.  We ignore errors
      * because this is only a hint.
 #if defined(HAVE_SYNC_FILE_RANGE)
     (void) sync_file_range(fd, 0, 0, SYNC_FILE_RANGE_WRITE);
 #elif defined(USE_POSIX_FADVISE) && defined(POSIX_FADV_DONTNEED)
     (void) posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED);
 #error PG_FLUSH_DATA_WORKS should not have been defined

Looking for recent commits involving POSIX_FADV_DONTNEED I found r292326:


Backing this revision out allowed the initdb process to complete.

My current theory is that some how we’re getting ENOLCK or EAGAIN from the 
BUF_TIMELOCK call in bnoreuselist:


Leading to an infinite loop in vop_stdadvise:


I haven’t managed to dig any deeper than that yet.

Is there any other information I could give you to help narrow this down?


freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to