Обсуждение: 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