Обсуждение: BUG #12344: libcurses issue with psql binary of Solaris package

Поиск
Список
Период
Сортировка

BUG #12344: libcurses issue with psql binary of Solaris package

От
egoitz@sarenet.es
Дата:
The following bug has been logged on the website:

Bug reference:      12344
Logged by:          Egoitz Aurrekoetxea
Email address:      egoitz@sarenet.es
PostgreSQL version: 9.4.0
Operating system:   Solaris 11.2 (5.11 11.2 i86pc i386 i86pc)
Description:

Good morning,

I'm giving a try to
https://ftp.postgresql.org/pub/binary/v9.4.0/solaris/solaris11/i386/postgresql-9.4.0-S11.i386-64.tar.bz2
under Solaris 11.2. All seems to be running fine although I have found an
issue running the psql binary. It generates a core if you hit for example
CTRL+A after writting an amount of text. I do paste here the test content
and the core in order to fixed...



    pgsql@themachine:~$ /usr/postgres/9.4-pgdg/bin/psql
theconnectingdatabase
    psql (9.4.0)
    Type "help" for help.

    theconnectingdatabase=#
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaSegmentation Fault
(`core' generado)

(you write the aaaaas and later CTRL+A)

    pgsql@themachine:~$
    pgsql@themachine:~$
    pgsql@themachine:~$
    pgsql@themachine:~$ gdb /usr/postgres/9.4-pgdg/bin/psql core
    GNU gdb (GDB) 7.6
    Copyright (C) 2013 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
    and "show warranty" for details.
    This GDB was configured as "i386-pc-solaris2.11".
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>...
    Reading symbols from /usr/postgres/9.4-pgdg/bin/psql...done.
    [New LWP 1]
    [New LWP 1]
    [Thread debugging using libthread_db enabled]
    [New Thread 1 (LWP 1)]
    Core was generated by `/usr/postgres/9.4-pgdg/bin/psql
theconnectingdatabase'.
    Program terminated with signal 11, Segmentation fault.
    #0  0xffff80ffbd5636b1 in tputs () from /lib/64/libcurses.so.1
    (gdb) bt
    #0  0xffff80ffbd5636b1 in tputs () from /lib/64/libcurses.so.1
    #1  0x00000000004612fb in term_move_to_char ()
    #2  0x000000000045f366 in re_refresh_cursor ()
    #3  0x000000000045e39f in el_gets ()
    #4  0x00000000004561d0 in readline ()
    #5  0x0000000000425f75 in gets_interactive ()
    #6  0x0000000000426c0b in MainLoop ()
    #7  0x000000000042bd89 in main ()
    (gdb)

    uname -ar
    SunOS themachine 5.11 11.2 i86pc i386 i86pc

The server part seems to be running fine.

Thank you so much,
Best regards

Re: BUG #12344: libcurses issue with psql binary of Solaris package

От
Tom Lane
Дата:
egoitz@sarenet.es writes:
> I'm giving a try to
> https://ftp.postgresql.org/pub/binary/v9.4.0/solaris/solaris11/i386/postgresql-9.4.0-S11.i386-64.tar.bz2
> under Solaris 11.2. All seems to be running fine although I have found an
> issue running the psql binary. It generates a core if you hit for example
> CTRL+A after writting an amount of text. I do paste here the test content
> and the core in order to fixed...

This is evidently a bug in libreadline or libedit (whichever you're
using), and almost certainly has nothing to do with psql proper.

The mention of el_gets() in the stack trace makes me suspect that it's
libedit, which is not terribly surprising because frankly we've seen a
darn lot of nasty bugs in that library.  They do fix 'em, so you could try
getting a newer version of libedit.  Or you could get GNU readline and
rebuild against that.  TBH I'd recommend the latter solution.

            regards, tom lane

Re: BUG #12344: libcurses issue with psql binary of Solaris package

От
Egoitz Aurrekoetxea
Дата:
Hello!,

And by the way=E2=80=A6 have done some checks=E2=80=A6.

Have just build Postgresql 9.4.0 in Solaris 11.2 with this flags=E2=80=A6.=


export CC=3D'/usr/gcc/4.8/bin/gcc -m64'
export CXX=3D'/usr/gcc/4.8/bin/c++ -m64'
export LDFLAGS=3D'-L/usr/local/lib -R/usr/local/lib'
export CPPFLAGS=3D'-I/usr/local/include'

later=20

 ./configure --prefix=3D/tmp/postgresql-prueba
 gmake

Just for ensuring was a bug in some Solaris library=E2=80=A6=E2=80=A6 =
and not a versioning issue (the package is compiled against or =
whatever=E2=80=A6.) or whatever=E2=80=A6=20

/tmp/prueba-comp-postgres/postgresql-9.4.0/src/bin/psql# ./psql
ld.so.1: psql: fatal: libpq.so.5: open failed: No such file or directory
Killed

It has not build libpq which I don=E2=80=99t really know why not=E2=80=A6 =
but like was just for the testing purpose=E2=80=A6. have copied the =
Postgresql binary package for Solaris libpq.so* files=E2=80=A6.

/tmp/prueba-comp-postgres/postgresql-9.4.0/src/bin/psql# cp =
/usr/postgres/9.4-pgdg/lib/libpq.so* .

Later=E2=80=A6. have done a :=20

export =
LD_LIBRARY_PATH=3D'/tmp/prueba-comp-postgres/postgresql-9.4.0/src/bin/psql=
'
And voil=C3=A0 :=20
/tmp/prueba-comp-postgres/postgresql-9.4.0/src/bin/psql# ./psql
psql: FATAL:  role "root" does not exist
root@themachine:/tmp/prueba-comp-postgres/postgresql-9.4.0/src/bin/psql# =
./psql -U thedatabase -h localhost
psql (9.4.0)
Type "help" for help.

thedatabase=3D# =
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
thedatabase-#=20
thedatabase-#=20
thedatabase-# ;
NOTICE:  identifier =
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=
" will be truncated to =
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
ERROR:  syntax error at or near =
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=
"
LINE 1: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa...
        ^
thedatabase=3D# select * from pg_stat_activity;
thedatabase=3D# =
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
thedatabase-# ;
NOTICE:  identifier =
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" =
will be truncated to =
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
ERROR:  syntax error at or near =
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
LINE 1: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa...
        ^
thedatabase=3D#=20
thedatabase=3D#=20
thedatabase=3D#=20
thedatabase=3D# \q
root@themachine:/tmp/prueba-comp-postgres/postgresql-9.4.0/src/bin/psql#=20=


It=E2=80=99s not being broken now=E2=80=A6=E2=80=A6 So perhaps is that =
it was build against for instance Solaris 11 not Solaris 11.2 and some =
issue exist with that linkage=E2=80=A6. done with a previous =
version=E2=80=A6..

If you tell me how=E2=80=A6 I wouldn=E2=80=99t mind creating it for =
Solaris 11.2 again the Postgresql package and donating it to you=E2=80=A6.=

What is the proper way of building in Solaris?? With libpq and all =
components?

Thank you so much,
Best regards,


Egoitz Aurrekoetxea
Departamento de sistemas
944 209 470
Parque Tecnol=C3=B3gico. Edificio 103
48170 Zamudio (Bizkaia)
egoitz@sarenet.es <mailto:egoitz@sarenet.es>
www.sarenet.es <http://www.sarenet.es/>
Antes de imprimir este correo electr=C3=B3nico piense si es necesario =
hacerlo.

> El 26/12/2014, a las 17:07, Egoitz Aurrekoetxea <egoitz@sarenet.es> =
escribi=C3=B3:
>=20
> Good afternoon,
>=20
> Thank you so much for the fast response. If I let it that way, without =
rebuilding and knowing the issue in one of the libraries mentioned=20
> by you, could this just bug end by affecting the Postgresql server =
part in some way?.
>=20
> Thank you so much,
> Best regards,
>=20
>=20
> Egoitz Aurrekoetxea
> Departamento de sistemas
> 944 209 470
> Parque Tecnol=C3=B3gico. Edificio 103
> 48170 Zamudio (Bizkaia)
> egoitz@sarenet.es <mailto:egoitz@sarenet.es>
> www.sarenet.es <http://www.sarenet.es/>
> Antes de imprimir este correo electr=C3=B3nico piense si es necesario =
hacerlo.
>=20
>> El 26/12/2014, a las 16:39, Tom Lane <tgl@sss.pgh.pa.us =
<mailto:tgl@sss.pgh.pa.us>> escribi=C3=B3:
>>=20
>> egoitz@sarenet.es <mailto:egoitz@sarenet.es> writes:
>>> I'm giving a try to
>>> =
https://ftp.postgresql.org/pub/binary/v9.4.0/solaris/solaris11/i386/postgr=
esql-9.4.0-S11.i386-64.tar.bz2 =
<https://ftp.postgresql.org/pub/binary/v9.4.0/solaris/solaris11/i386/postg=
resql-9.4.0-S11.i386-64.tar.bz2>
>>> under Solaris 11.2. All seems to be running fine although I have =
found an
>>> issue running the psql binary. It generates a core if you hit for =
example
>>> CTRL+A after writting an amount of text. I do paste here the test =
content
>>> and the core in order to fixed...
>>=20
>> This is evidently a bug in libreadline or libedit (whichever you're
>> using), and almost certainly has nothing to do with psql proper.
>>=20
>> The mention of el_gets() in the stack trace makes me suspect that =
it's
>> libedit, which is not terribly surprising because frankly we've seen =
a
>> darn lot of nasty bugs in that library.  They do fix 'em, so you =
could try
>> getting a newer version of libedit.  Or you could get GNU readline =
and
>> rebuild against that.  TBH I'd recommend the latter solution.
>>=20
>>             regards, tom lane
>=20

Re: BUG #12344: libcurses issue with psql binary of Solaris package

От
Egoitz Aurrekoetxea
Дата:
Good afternoon,

Thank you so much for the fast response. If I let it that way, without =
rebuilding and knowing the issue in one of the libraries mentioned=20
by you, could this just bug end by affecting the Postgresql server part =
in some way?.

Thank you so much,
Best regards,


Egoitz Aurrekoetxea
Departamento de sistemas
944 209 470
Parque Tecnol=C3=B3gico. Edificio 103
48170 Zamudio (Bizkaia)
egoitz@sarenet.es <mailto:egoitz@sarenet.es>
www.sarenet.es <http://www.sarenet.es/>
Antes de imprimir este correo electr=C3=B3nico piense si es necesario =
hacerlo.

> El 26/12/2014, a las 16:39, Tom Lane <tgl@sss.pgh.pa.us> escribi=C3=B3:
>=20
> egoitz@sarenet.es writes:
>> I'm giving a try to
>> =
https://ftp.postgresql.org/pub/binary/v9.4.0/solaris/solaris11/i386/postgr=
esql-9.4.0-S11.i386-64.tar.bz2
>> under Solaris 11.2. All seems to be running fine although I have =
found an
>> issue running the psql binary. It generates a core if you hit for =
example
>> CTRL+A after writting an amount of text. I do paste here the test =
content
>> and the core in order to fixed...
>=20
> This is evidently a bug in libreadline or libedit (whichever you're
> using), and almost certainly has nothing to do with psql proper.
>=20
> The mention of el_gets() in the stack trace makes me suspect that it's
> libedit, which is not terribly surprising because frankly we've seen a
> darn lot of nasty bugs in that library.  They do fix 'em, so you could =
try
> getting a newer version of libedit.  Or you could get GNU readline and
> rebuild against that.  TBH I'd recommend the latter solution.
>=20
>             regards, tom lane

Re: BUG #12344: libcurses issue with psql binary of Solaris package

От
Egoitz Aurrekoetxea
Дата:
Good afternoon,

Ok, so=E2=80=A6.

Have been debugging all this issue and have seen the following details =
and assumptions :=20

- Binary package for Solaris downloadable in =
http://www.postgresql.org/ftp/binary/v9.4.0/solaris/solaris11/i386/ =
<http://www.postgresql.org/ftp/binary/v9.4.0/solaris/solaris11/i386/> =
will probably be for Solaris 11.0 not 11.1 or 11.2=E2=80=A6 unless it =
seems to be built there=E2=80=A6
- It has been build with Solaris Studio 11 compilers which don=E2=80=99t =
really know for Solaris 11 but for Solaris 11.2 are slightly old=E2=80=A6.=
 apart=E2=80=A6 why this compilers were used instead of GCC installable =
with pkg install?
- Have found in the config (pg_config output) too some flag that seem to =
be only valid for Sparc arch=E2=80=A6

And some other thing I did not remember at present instant but I believe =
saw=E2=80=A6.

Well like I needed to use Postgresql on Solaris=E2=80=A6 I rebuilt it=E2=80=
=A6 I did use all systems default libraries=E2=80=A6 I didn=E2=80=99t =
install any kind of Sunfreeware or whatever library=E2=80=A6.

So I have build successfully (unless until now, have not seen any issue =
with the binaries) in Solaris 11.2 concretely the OS is:=20

uname -ar
SunOS themachine 5.11 11.2 i86pc i386 i86pc

cat /etc/release=20
                             Oracle Solaris 11.2 X86
  Copyright (c) 1983, 2014, Oracle and/or its affiliates.  All rights =
reserved.
                             Assembled 23 June 2014


with just doing :=20

pkg install gcc-c++-48 gcc-c-48

export CC=3D'/usr/gcc/4.8/bin/gcc -m64'
export CXX=3D'/usr/gcc/4.8/bin/c++ -m64'
export LDFLAGS=3D'-L/usr/local/lib -R/usr/local/lib'
export CPPFLAGS=3D'-I/usr/local/include'
export CFLAGS=3D'-O3'
export PATH=3D$PATH':/usr/gnu/bin'

./configure --prefix=3D/opt/postgres94 --enable-nls =
--with-system-tzdata=3D/usr/share/lib/zoneinfo --with-tclconfig=3D/usr/lib=
 --with-python --with-tcl --with-pam --with-libedit-preferred =
--with-libxml --with-libxslt --enable-thread-safety  =
--enable-integer-datetimes
gmake
gmake install

Perhaps it would be better (instead of providing binaries) to include a =
script in the sources tar.gz that if you were in Solaris (I say in =
Solaris, because in FreeBSD for example, which is the main OS I do use, =
you build it easilly from ports, and in other systems like Linux=20
you normally have prebuilt) which checks the env, the packages installed =
and so=E2=80=A6 or just directly, to say to everybody=E2=80=A6 "For =
installing Postgresql in Solaris, you need to have a Virgin Solaris =
installation and just run later the -build-on-solaris.sh-" or whatever =
script in order=20
to start everybody in the same beginning point and later to run a script =
which for example does this same I have wrote before. I would say this =
is better than having, say old binaries or=E2=80=A6. and like building, =
let=E2=80=99s say, enforces you to have all required system libraries if =
you=20
want the code to be built if you say everyone to start at the same =
beginning point I think could be perhaps easier to offer an easy way to =
install Postgresql in Solaris.

Thank you very much for you=E2=80=99re help and hope this helps too,
Best regards,



Egoitz Aurrekoetxea
Departamento de sistemas
944 209 470
Parque Tecnol=C3=B3gico. Edificio 103
48170 Zamudio (Bizkaia)
egoitz@sarenet.es <mailto:egoitz@sarenet.es>
www.sarenet.es <http://www.sarenet.es/>
Antes de imprimir este correo electr=C3=B3nico piense si es necesario =
hacerlo.

> El 26/12/2014, a las 17:55, pgsql-bugs-owner@postgresql.org escribi=C3=B3=
:
>=20
> Your message to pgsql-bugs has been delayed, and requires the approval=20=

> of the moderators, for the following reason(s):
>=20
> The author (Egoitz Aurrekoetxea <egoitz@sarenet.es>)
>  is not a member of any of the restrict_post groups.
>=20
> If you do not wish the message to be posted, or have other concerns,=20=

> please send a message to the list owners at the following address:=20
>  pgsql-bugs-owner@postgresql.org
>=20
> Asunto: Re: [BUGS] BUG #12344: libcurses issue with psql binary of =
Solaris package
> De: Egoitz Aurrekoetxea <egoitz@sarenet.es>
> Fecha: 26 de diciembre de 2014, 17:55:40 CET
> Cc: pgsql-bugs@postgresql.org
> Para: Tom Lane <tgl@sss.pgh.pa.us>
>=20
>=20
> Hello!,
>=20
> And by the way=E2=80=A6 have done some checks=E2=80=A6.
>=20
> Have just build Postgresql 9.4.0 in Solaris 11.2 with this flags=E2=80=A6=
.
>=20
> export CC=3D'/usr/gcc/4.8/bin/gcc -m64'
> export CXX=3D'/usr/gcc/4.8/bin/c++ -m64'
> export LDFLAGS=3D'-L/usr/local/lib -R/usr/local/lib'
> export CPPFLAGS=3D'-I/usr/local/include'
>=20
> later=20
>=20
>  ./configure --prefix=3D/tmp/postgresql-prueba
>  gmake
>=20
> Just for ensuring was a bug in some Solaris library=E2=80=A6=E2=80=A6 =
and not a versioning issue (the package is compiled against or =
whatever=E2=80=A6.) or whatever=E2=80=A6=20
>=20
> /tmp/prueba-comp-postgres/postgresql-9.4.0/src/bin/psql# ./psql
> ld.so.1: psql: fatal: libpq.so.5: open failed: No such file or =
directory
> Killed
>=20
> It has not build libpq which I don=E2=80=99t really know why not=E2=80=A6=
 but like was just for the testing purpose=E2=80=A6. have copied the =
Postgresql binary package for Solaris libpq.so* files=E2=80=A6.
>=20
> /tmp/prueba-comp-postgres/postgresql-9.4.0/src/bin/psql# cp =
/usr/postgres/9.4-pgdg/lib/libpq.so* .
>=20
> Later=E2=80=A6. have done a :=20
>=20
> export =
LD_LIBRARY_PATH=3D'/tmp/prueba-comp-postgres/postgresql-9.4.0/src/bin/psql=
'
> And voil=C3=A0 :=20
> /tmp/prueba-comp-postgres/postgresql-9.4.0/src/bin/psql# ./psql
> psql: FATAL:  role "root" does not exist
> =
root@themachine:/tmp/prueba-comp-postgres/postgresql-9.4.0/src/bin/psql# =
./psql -U thedatabase -h localhost
> psql (9.4.0)
> Type "help" for help.
>=20
> thedatabase=3D# =
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> thedatabase-#=20
> thedatabase-#=20
> thedatabase-# ;
> NOTICE:  identifier =
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=
" will be truncated to =
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
> ERROR:  syntax error at or near =
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=
"
> LINE 1: =
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa...
>         ^
> thedatabase=3D# select * from pg_stat_activity;
> thedatabase=3D# =
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> thedatabase-# ;
> NOTICE:  identifier =
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" =
will be truncated to =
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
> ERROR:  syntax error at or near =
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
> LINE 1: =
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa...
>         ^
> thedatabase=3D#=20
> thedatabase=3D#=20
> thedatabase=3D#=20
> thedatabase=3D# \q
> =
root@themachine:/tmp/prueba-comp-postgres/postgresql-9.4.0/src/bin/psql#=20=

>=20
> It=E2=80=99s not being broken now=E2=80=A6=E2=80=A6 So perhaps is that =
it was build against for instance Solaris 11 not Solaris 11.2 and some =
issue exist with that linkage=E2=80=A6. done with a previous =
version=E2=80=A6..
>=20
> If you tell me how=E2=80=A6 I wouldn=E2=80=99t mind creating it for =
Solaris 11.2 again the Postgresql package and donating it to you=E2=80=A6.=

> What is the proper way of building in Solaris?? With libpq and all =
components?
>=20
> Thank you so much,
> Best regards,
>=20
>=20
> Egoitz Aurrekoetxea
> Departamento de sistemas
> 944 209 470
> Parque Tecnol=C3=B3gico. Edificio 103
> 48170 Zamudio (Bizkaia)
> egoitz@sarenet.es <mailto:egoitz@sarenet.es>
> www.sarenet.es <http://www.sarenet.es/>
> Antes de imprimir este correo electr=C3=B3nico piense si es necesario =
hacerlo.
>=20
>> El 26/12/2014, a las 17:07, Egoitz Aurrekoetxea <egoitz@sarenet.es =
<mailto:egoitz@sarenet.es>> escribi=C3=B3:
>>=20
>> Good afternoon,
>>=20
>> Thank you so much for the fast response. If I let it that way, =
without rebuilding and knowing the issue in one of the libraries =
mentioned=20
>> by you, could this just bug end by affecting the Postgresql server =
part in some way?.
>>=20
>> Thank you so much,
>> Best regards,
>>=20
>>=20
>> Egoitz Aurrekoetxea
>> Departamento de sistemas
>> 944 209 470
>> Parque Tecnol=C3=B3gico. Edificio 103
>> 48170 Zamudio (Bizkaia)
>> egoitz@sarenet.es <mailto:egoitz@sarenet.es>
>> www.sarenet.es <http://www.sarenet.es/>
>> Antes de imprimir este correo electr=C3=B3nico piense si es necesario =
hacerlo.
>>=20
>>> El 26/12/2014, a las 16:39, Tom Lane <tgl@sss.pgh.pa.us =
<mailto:tgl@sss.pgh.pa.us>> escribi=C3=B3:
>>>=20
>>> egoitz@sarenet.es <mailto:egoitz@sarenet.es> writes:
>>>> I'm giving a try to
>>>> =
https://ftp.postgresql.org/pub/binary/v9.4.0/solaris/solaris11/i386/postgr=
esql-9.4.0-S11.i386-64.tar.bz2 =
<https://ftp.postgresql.org/pub/binary/v9.4.0/solaris/solaris11/i386/postg=
resql-9.4.0-S11.i386-64.tar.bz2>
>>>> under Solaris 11.2. All seems to be running fine although I have =
found an
>>>> issue running the psql binary. It generates a core if you hit for =
example
>>>> CTRL+A after writting an amount of text. I do paste here the test =
content
>>>> and the core in order to fixed...
>>>=20
>>> This is evidently a bug in libreadline or libedit (whichever you're
>>> using), and almost certainly has nothing to do with psql proper.
>>>=20
>>> The mention of el_gets() in the stack trace makes me suspect that =
it's
>>> libedit, which is not terribly surprising because frankly we've seen =
a
>>> darn lot of nasty bugs in that library.  They do fix 'em, so you =
could try
>>> getting a newer version of libedit.  Or you could get GNU readline =
and
>>> rebuild against that.  TBH I'd recommend the latter solution.
>>>=20
>>>             regards, tom lane
>>=20
>=20
>=20
>=20