Hello, I've built the port on 10.1 with raster support enabled: PostgreSQL 9.4.1 on amd64-portbld-freebsd10.1, compiled by FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512, 64-bit POSTGIS="2.1.7 r13414" GEOS="3.4.2-CAPI-1.8.2 r3921" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.11.2, released 2015/02/10" LIBXML="2.9.2" LIBJSON="UNKNOWN" RASTER Postgres occasionally core dumps, I haven't really found what is causing this: #0 0x000000000054219e in std_typanalyze () #1 0x000000080bdb4d30 in geometry_estimated_extent () from /usr/local/lib/postgresql/postgis-2.1.so #2 0x000000000053ff38 in analyze_rel () #3 0x000000000053ecd0 in analyze_rel () #4 0x000000000058f336 in vacuum () #5 0x000000000061f01e in AutoVacuumShmemInit () #6 0x000000000061ddbe in StartAutoVacWorker () #7 0x000000000061da3b in StartAutoVacWorker () #8 0x000000000062c477 in PostmasterMain () #9 0x0000000800d6247a in swapcontext () from /lib/libthr.so.3 #10 0x0000000800d62062 in sigaction () from /lib/libthr.so.3 #11 <signal handler called> #12 0x0000000801ee2b7a in select () from /lib/libc.so.7 #13 0x0000000800d5fb32 in select () from /lib/libthr.so.3 #14 0x000000000062a6de in PostmasterMain () #15 0x00000000005c86e4 in main ()
I haven't been able to reproduce this here, but I could use some additional details. Does the database have raster data loaded? If so, is it using internal storage or external files? Can you trigger the crash by running a vacuum on the table containing raster data?
10.1 is EOL. No reply since 2015-07-19. I think this could be closed.