Thread: bug reporting
Pgadmin 3.1 don t work (operations like insert rows) with columns named in russian language (title of column in russian language). But the same operations using PhpPgAdmin - all works very well, right. And if replace russian title of column with equivalent in english - all works very well. PgAdmin responds the message: "2003-10-03 14:15:15 ERROR : Column not found in pgSet: åùå_êîëîíêà". Operation System: Windows XP, distribution binary (zip), language russian.
Alexandr S wrote: > Pgadmin 3.1 don t work (operations like insert rows) with columns > named in russian language (title of column in russian language). But > the same operations using PhpPgAdmin - all works very well, right. > And if replace russian title of column with equivalent in english - > all works very well. PgAdmin responds the message: "2003-10-03 > 14:15:15 ERROR : Column not found in pgSet: еще_колонка". Operation > System: Windows XP, distribution binary (zip), language russian. > Hi Alexandr, you're on the wrong list, please use pgadmin-support for pgAdmin related questions. Which tool did you use to insert the data? Regards, Andreas
Hi,
the following configure/make batch with postgresql-7.4beta4
results with the error below.
That is to say, make does work fine,
but make check results in an error. Oviously the target-directory
given with prefix is already used in some way with make check
(when make install is not yet run). This error did not occur with 7.3
versions, where the make test seemed to restrict itself to the source
directory and did not touch the target directory given by prefix.
The OS is Suse 8.2 with bison updated to 1.85 as required because of a
resp. warning from configure.
SourceDir="/usr/local/src/postgresql-7.4beta4"
TargetDir="/opt/doka/"
PORTNR=5432
export LC_LANG=de_DE@euro
export LC_COLLATE=de_DE
datum=`date +%d%b%Y_%H%M`
make clean
./configure --prefix=$TargetDir/pgsql \
--enable-nls='de' \
--with-pgport=$PORTNR \
--with-tcl \
--with-odbc \
--with-perl \
--with-openssl \
--with-python
make check
This did result in the following ...
============== removing existing temp installation ==============
============== creating temporary installation ==============
============== initializing database system ==============
============== starting postmaster ==============
running on port 65432 with pid 48
============== creating database "regression" ==============
/usr/local/src/postgresql-7.4beta4/src/test/regress/./tmp_check/install//opt/doka//pgsql/bin/createdb:
relocation error:
/us/local/src/postgresql-7.4beta4/src/test/regress/./tmp_check/install//opt/doka//pgsql/bin/createdb:
undefined symbol: get_proname
pg_regress: createdb failed
make[2]: *** [check] Fehler 2
make[2]: Leaving directory
`/usr/local/src/postgresql-7.4beta4/src/test/regress'
make[1]: *** [check] Fehler 2
make[1]: Leaving directory `/usr/local/src/postgresql-7.4beta4/src/test'
make: *** [check] Fehler 2
postgres@zs:/usr/local/src/postgresql-7.4beta4>
Regards
Christoph Becker
Christoph Becker <CGBecker@gmx.de> writes:
> ============== creating database "regression" ==============
> /usr/local/src/postgresql-7.4beta4/src/test/regress/./tmp_check/install//opt/doka//pgsql/bin/createdb:
> relocation error:
> /us/local/src/postgresql-7.4beta4/src/test/regress/./tmp_check/install//opt/doka//pgsql/bin/createdb:
> undefined symbol: get_proname
> pg_regress: createdb failed
Hm. I have a feeling your temp installation is somehow linking to an
old version of libpq, because that's the most common reason for
link-time failures in "make check". But I don't understand the
reference to 'get_proname'. There is no occurrence of that string in
either current sources or any recent PG release.
regards, tom lane
tgl@sss.pgh.pa.us wrote: > Christoph Becker <CGBecker@gmx.de> writes: >> ============== creating database "regression" ============== >> /usr/local/src/postgresql-7.4beta4/src/test/regress/./tmp_check/install//opt/doka//pgsql/bin/createdb: >> relocation error: >> /us/local/src/postgresql-7.4beta4/src/test/regress/./tmp_check/install//opt/doka//pgsql/bin/createdb: >> undefined symbol: get_proname >> pg_regress: createdb failed > > Hm. I have a feeling your temp installation is somehow linking to an > old version of libpq, because that's the most common reason for > link-time failures in "make check". But I don't understand the > reference to 'get_proname'. There is no occurrence of that string in > either current sources or any recent PG release. I got the same error with beta1, but the symbol was "get_progname" not "get_proname". Perhaps the above is a typo. I also thought the thing was somehow using my current 7.3 install when linking the 7.4 tests. Didn't happen with beta2, but could be because then I had beta1 installed.
ljb <ljb220@mindspring.com> writes:
> I got the same error with beta1, but the symbol was "get_progname"
> not "get_proname". Perhaps the above is a typo.
"get_progname" would make sense, because that's a symbol defined in
libpgport in 7.4 that did not exist in 7.3. So if the dynamic linker
was finding your 7.3 PG library directory instead of 7.4, you'd likely
get this error.
regards, tom lane
tgl@sss.pgh.pa.us wrote: > ljb <ljb220@mindspring.com> writes: >> I got the same error with beta1, but the symbol was "get_progname" >> not "get_proname". Perhaps the above is a typo. > > "get_progname" would make sense, because that's a symbol defined in > libpgport in 7.4 that did not exist in 7.3. So if the dynamic linker > was finding your 7.3 PG library directory instead of 7.4, you'd likely > get this error. Confirmed. Perhaps this should be looked into. On my system, "make check" works fine if there is no existing PostgreSQL installation. But if there is, we seem to prefer the existing installation's libraries over what pg_regress sets LD_LIBRARY_PATH to (the newly built software). This means that "make check" will either fail in createdb (if the existing install is 7.3, for example) or work but actually be testing the newly built programs using the existing version's run-time libpq library.
ljb <ljb220@mindspring.com> writes:
> Confirmed. Perhaps this should be looked into. On my system, "make check"
> works fine if there is no existing PostgreSQL installation. But if there
> is, we seem to prefer the existing installation's libraries over what
> pg_regress sets LD_LIBRARY_PATH to (the newly built software). This means
> that "make check" will either fail in createdb (if the existing install is
> 7.3, for example) or work but actually be testing the newly built programs
> using the existing version's run-time libpq library.
Yeah, we have seen this before on various platforms. On some,
LD_LIBRARY_PATH isn't actually anything the dynamic linker pays
attention to, and on others, it is trumped by the installation rpath
built into the executables. Not putting an rpath into the executables
would make life better for "make check" at the cost of making the
executables much more fragile in actual use. I don't see a good
solution :-( but if you do, step right up to the plate ...
regards, tom lane
tgl@sss.pgh.pa.us wrote:
> Yeah, we have seen this before on various platforms. On some,
> LD_LIBRARY_PATH isn't actually anything the dynamic linker pays
> attention to, and on others, it is trumped by the installation rpath
> built into the executables. Not putting an rpath into the executables
> would make life better for "make check" at the cost of making the
> executables much more fragile in actual use. I don't see a good
> solution :-( but if you do, step right up to the plate ...
Well, I'm not going to be the one who suggests that adding:
export LD_PRELOAD=$libdir/libpq.so
to pg_regress.sh before the initdb command will fix it (on Linux).
Because the more I think about it, the less I like the idea of "make check"
as a way to validate PostgreSQL. Not only because it looks like some of us
may have actually been testing a hybrid "new programs/old libraries"
combination, but because "make check" uses a temporary installation. For
acceptance testing, I want to know that it was built and installed
properly, so I'll have to use "make installcheck" after installation. (Say,
why isn't this listed in INSTALL anymore?)