Обсуждение: psql bug
After editing query with external editor psql exits on Ctrl-C: % psql postgres SET Timing is on. psql (9.2beta1) Type "help" for help. postgres=# --- Ctrl-C postgres=# --- Ctrl-C postgres=# --- Ctrl-C postgres=# \e ... postgres=# --- Ctrl-C % Some details: external editor - nvi/vim, OS FreeBSD 9.0 64-bit, % ldd /usr/local/pgsql/bin/psql /usr/local/pgsql/bin/psql: libpq.so.5 => /usr/local/pgsql/lib/libpq.so.5 (0x8008b4000) libreadline.so.8 =>/lib/libreadline.so.8 (0x800ae5000) libc.so.7 => /lib/libc.so.7 (0x800d24000) libthr.so.3 => /lib/libthr.so.3(0x80106a000) libncurses.so.8 => /lib/libncurses.so.8 (0x80128d000) -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/
Teodor Sigaev <teodor@sigaev.ru> writes: > After editing query with external editor psql exits on Ctrl-C: FWIW, I failed to reproduce that on any of my machines. Maybe your editor is leaving the tty in a funny state? regards, tom lane
will investigate that Tom Lane wrote: > Teodor Sigaev<teodor@sigaev.ru> writes: >> After editing query with external editor psql exits on Ctrl-C: > > FWIW, I failed to reproduce that on any of my machines. Maybe > your editor is leaving the tty in a funny state? > > regards, tom lane -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/
> FWIW, I failed to reproduce that on any of my machines. Maybe > your editor is leaving the tty in a funny state? Seems system() call cleanups sigaction state on FreeBSD. I've modify void setup_cancel_handler(void) { fprintf(stderr, "%p -> %p\n", pqsignal(SIGINT, handle_sigint), handle_sigint); } and add it around system() call. Next: % export EDITOR=echo % psql postgres 0x0 -> 0x409620 SET Timing is on. psql (9.2beta1) Type "help" for help. postgres=# \e 0x409620 -> 0x409620 /tmp/psql.edit.7997.sql 0x0 -> 0x409620 postgres=# -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/
> Seems system() call cleanups sigaction state on FreeBSD. The root of problem is a threading library. In FreeBSD there are two versions of sigaction() (system() and others) depending on thread enabled. libpq library is compiled by default with -pthread switch but psql is linked without that. This mixed linkage is a reason why system() call for external program loses signal handler. Next, configure script correctly sets PTHREAD_* variables but PTHREAD_LIBS is not used for psql linking. What is the best way to fix that? I suggest to add PTHREAD_LIBS to linking psql at least. Although, suppose, it could be a reason for other cryptic bugs. I didn't test this solution on other OSes, but, suppose, it will work. -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/
Teodor Sigaev <teodor@sigaev.ru> writes: >> Seems system() call cleanups sigaction state on FreeBSD. > The root of problem is a threading library. In FreeBSD there are two versions of > sigaction() (system() and others) depending on thread enabled. libpq library is > compiled by default with -pthread switch but psql is linked without that. > This mixed linkage is a reason why system() call for external program loses > signal handler. > Next, configure script correctly sets PTHREAD_* variables but PTHREAD_LIBS is > not used for psql linking. > What is the best way to fix that? I suggest to add PTHREAD_LIBS to linking psql > at least. Although, suppose, it could be a reason for other cryptic bugs. We could probably "fix" this by adding something like this to Makefile.freebsd: libpq += $(PTHREAD_LIBS) However, the more I think about this, the more I think it is a FreeBSD bug and the right solution is to complain loudly to the maintainers of that platform. The above hack might fix things for programs we ship as part of Postgres, but what of other programs using libpq? It cannot be rational to expect that if libpq is linked to libpthread, then every program that links to libpq must also be explicitly linked to libpthread. FreeBSD's linker is broken and they need to fix it, or else they need to fix libpthread to be less invasive. (Another reason for thinking this is that surely we'd have heard about it before if this behavior were of long standing. My money is on a fairly recently introduced bug.) regards, tom lane