On Saturday 14 February 2015, Hugo Osvaldo Barrera wrote: > On 2015-02-14 02:28, Abel Abraham Camarillo Ojeda wrote: > > On Sat, Feb 14, 2015 at 2:12 AM, Hugo Osvaldo Barrera <h...@barrera.io> > > wrote: > > > On 2015-02-13 13:20, Stuart Henderson wrote: > > >> On 2015-02-12, Hugo Osvaldo Barrera <h...@barrera.io> wrote: > > >> > On 2015-02-12 10:18, Stuart Henderson wrote: > > >> >> On 2015-02-11, Hugo Osvaldo Barrera <h...@barrera.io> wrote: > > >> >> > Can > > >> >> > someone else confirm postgres9.4 work fine on the latest > > >> >> > -snapshot? > > > > > > (the > > > > > >> >> > confirmation would be helpful to reafirm that it's not an issue > > with > > > > some > > > > > >> >> > dependency or library). > > >> >> > > >> >> Works fine on my bacula box, running 9.4.1 (and previously 9.4.0) > > >> >> on > > > > > > amd64. > > > > > >> > Ok, so now I know that the issue is on my end. Which leaves me even > > more > > > >> > confused. You're running the latest snapshots too, right? (eg: the > > ones > > > > from > > > > > >> > feb 10th?). > > >> > > > >> > Aside from a clean install, do you have any more changes? Perhaps > > > > > > login.conf? > > > > > >> I have the login.conf section from the example in the pkg-readme, > > >> > > >> postgresql:\ > > >> > > >> :openfiles-cur=768:\ > > >> :tc=daemon: > > >> > > >> and this in sysctl.conf > > >> > > >> # postgresql > > >> kern.seminfo.semmni=256 > > >> kern.seminfo.semmns=2048 > > >> kern.shminfo.shmmax=50331648 > > >> > > >> <sthen@hutch:~:532>$ ls -l /bin/ls /usr/local/bin/postgres > > >> -r-xr-xr-x 1 root bin 267968 Feb 10 23:19 /bin/ls* > > >> -r-xr-xr-x 1 root bin 6508711 Feb 9 03:21 /usr/local/bin/postgres* > > >> > > >> <sthen@hutch:~:533>$ sysctl kern.version > > >> kern.version=OpenBSD 5.7-beta (GENERIC) #797: Tue Feb 10 16:26:12 MST > > 2015 > > > >> t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > > > > > > Thanks for all the details. It looks like almost everything is > > > identical except our kernels (I had a few extra fields in sysctl.conf > > > edited for > > pg, > > > > but > > > reverted them just to make sure they weren't screwing up). > > > > > > # sysctl kern.version > > > kern.version=OpenBSD 5.7-beta (GENERIC.MP) #852: Tue Feb 10 16:31:16 > > MST > > > > 2015 > > > t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > > I switched to the SP kernel just to discard any possible regressions > > > that might > > > be affecting this scenario, but no change. > > > > > > It looks like the issue is elsewhere, but I've no idea where to look. > > > I've > > so > > > > far failed to build postgresql-server with debug symbols enabled too, > > > but that's just lack of knowledge on my part. > > > > > > -- > > > Hugo Osvaldo Barrera > > > A: Because we read from top to bottom, left to right. > > > Q: Why should I start my reply below the quoted text? > > > > > > [demime 1.01d removed an attachment of type application/pgp-signature] > > > > you should give more information about how to reproduce this problem, > > how accurately can you reproduce it, are you sending just a given query > > and it always crashes? > > It always crashes extremely frequently. I haven't noticed a pattern, and > the server never lives more than a few senconds. No particular query seems > to trigger it, and adding log_statement showed that it may even crash > *before* any > queries are executed (see below as well). > > > you should get more error context, maybe try log_statement into > > postgresql.conf > > > and try to log all statements and see which one crashes it... > > > > http://www.postgresql.org/docs/9.4/static/runtime-config-logging.html > > > > are you using any custom C extension? > > Nope, this is a plain default install from snapshots with nothing extra. > > > did you dump and restore database ? did you use 'custom format' or > > 'plain format' ? > > My latest tests reproduce the same issue on a clean "out-of-the-box" db > (eg: not importing any data). > > > there where any errors on import? - postgres just warns about some > > import errors, > > which in my opinion are severe... > > This is a log with log_statement and a most logging turned on. I'd only run > the > server *once* post-initialization before this. The database was completely > empty: > > http://sprunge.us/UVGj > > While a query managed to get through once, the server usually crashed > before that happens.
The interesting/useful part is: LOG: statement: SELECT ... ORDER BY c.oid LOG: server process (PID 11531) was terminated by signal 6: Abort trap So the server process is being sent a SIGABRT, which is causing it to terminate. There is a good chance this this is coming from the stack protector, which sends a SIGABRT if the stack is smashed. Is there anything in dmesg or syslog that correlates? Failing that your next step is likely to run it under gdb and get a backtrace from the point where the SIGABRT occurs. You can also bisect by rolling back to an older snapshot to see if you can locate the change that has triggered the issue. > Here's another, finer-grained log, with nothing useful (apperently) either: > > http://sprunge.us/FQaJ > > Thanks, > > -- > Hugo Osvaldo Barrera > A: Because we read from top to bottom, left to right. > Q: Why should I start my reply below the quoted text? > > [demime 1.01d removed an attachment of type application/pgp-signature] -- "Action without study is fatal. Study without action is futile." -- Mary Ritter Beard
