Re: [BUGS] BUG #2260: PGCrypto Memory Problem
Michael Fuhr <[EMAIL PROTECTED]> writes:
> My non-OpenSSL build shows no memory leak, so the leak and OpenSSL
> seem to be correlated. I'd be more inclined to suspect a bug in
> pgcrypto's OpenSSL-specific code than in OpenSSL itself. Will keep
> digging.
The problem appears to be here:
static void
digest_finish(PX_MD * h, uint8 *dst)
{
EVP_MD_CTX *ctx = (EVP_MD_CTX *) h->p.ptr;
const EVP_MD *md = EVP_MD_CTX_md(ctx);
EVP_DigestFinal(ctx, dst, NULL);
/*
* Some builds of 0.9.7x clear all of ctx in EVP_DigestFinal. Fix it by
* reinitializing ctx.
*/
EVP_DigestInit(ctx, md);
}
It looks like this results in a leak of the entire OpenSSL context for
each call to pg_crypt. Marko, I trust you've got a better solution for
this ...
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2260: PGCrypto Memory Problem
On Wed, Feb 15, 2006 at 02:28:33PM -0500, Tom Lane wrote: > Michael Fuhr <[EMAIL PROTECTED]> writes: > > Did you test OpenSSL builds? > > Nope, I did not, and that's a good point. Will try again with openssl. My non-OpenSSL build shows no memory leak, so the leak and OpenSSL seem to be correlated. I'd be more inclined to suspect a bug in pgcrypto's OpenSSL-specific code than in OpenSSL itself. Will keep digging. -- Michael Fuhr ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2260: PGCrypto Memory Problem
Michael Fuhr <[EMAIL PROTECTED]> writes: > On Wed, Feb 15, 2006 at 01:43:18PM -0500, Tom Lane wrote: >> Interesting, because I see no leak with this example on Fedora 4 or >> HPUX. Platform dependency is sounding more and more likely. > Did you test OpenSSL builds? Nope, I did not, and that's a good point. Will try again with openssl. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2170: --rpath option is skipping shared libs
Better version of patch. Only kicks in when asked for
with --enable-rpath_sl
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> "Lee Thompson" <[EMAIL PROTECTED]> writes:
> > +if test "$enable_rpath" = yes ; then
> > + LIBDIRS="$LIBDIRS -Wl,-R$dir"
> > +fi
>
> What is this supposed to accomplish? (Other than
> probably breaking
> every non-gcc toolchain on the planet...)
>
> regards, tom lane
>
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com diff -Nru postgresql-8.1.2.orig/configure postgresql-8.1.2/configure
--- postgresql-8.1.2.orig/configure 2006-02-15 10:00:03.0 -0600
+++ postgresql-8.1.2/configure 2006-02-15 11:44:10.0 -0600
@@ -314,7 +314,7 @@
# include
#endif"
-ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS configure_args build build_cpu build_vendor build_os host host_cpu host_vendor host_os PORTNAME docdir enable_nls WANTED_LANGUAGES default_port enable_shared enable_rpath enable_debug CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CPP GCC TAS autodepend INCLUDES enable_thread_safety with_tcl with_perl with_python with_krb5 krb_srvtab with_pam with_bonjour with_openssl with_zlib EGREP ELF_SYS LDFLAGS_SL AWK FLEX FLEXFLAGS LN_S LD with_gnu_ld ld_R_works RANLIB ac_ct_RANLIB LORDER TAR STRIP ac_ct_STRIP STRIP_STATIC_LIB STRIP_SHARED_LIB YACC YFLAGS PERL perl_archlibexp perl_privlibexp perl_useshrplib perl_embed_ldflags PYTHON python_versi
on python_configdir python_includespec python_libdir python_libspec python_additional_libs HAVE_IPV6 LIBOBJS acx_pthread_config PTHREAD_CC PTHREAD_LIBS PTHREAD_CFLAGS HAVE_POSIX_SIGNALS MSGFMT MSGMERGE XGETTEXT localedir TCLSH TCL_CONFIG_SH TCL_INCLUDE_SPEC TCL_LIB_FILE TCL_LIBS TCL_LIB_SPEC TCL_SHARED_BUILD TCL_SHLIB_LD_LIBS NSGMLS JADE have_docbook DOCBOOKSTYLE COLLATEINDEX SGMLSPL vpath_build LTLIBOBJS'
+ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS configure_args build build_cpu build_vendor build_os host host_cpu host_vendor host_os PORTNAME docdir enable_nls WANTED_LANGUAGES default_port enable_shared enable_rpath enable_rpath_sl enable_debug CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CPP GCC TAS autodepend INCLUDES enable_thread_safety with_tcl with_perl with_python with_krb5 krb_srvtab with_pam with_bonjour with_openssl with_zlib EGREP ELF_SYS LDFLAGS_SL AWK FLEX FLEXFLAGS LN_S LD with_gnu_ld ld_R_works RANLIB ac_ct_RANLIB LORDER TAR STRIP ac_ct_STRIP STRIP_STATIC_LIB STRIP_SHARED_LIB YACC YFLAGS PERL perl_archlibexp perl_privlibexp perl_useshrplib perl_embed_ldflags PYT
HON python_version python_configdir python_includespec python_libdir python_libspec python_additional_libs HAVE_IPV6 LIBOBJS acx_pthread_config PTHREAD_CC PTHREAD_LIBS PTHREAD_CFLAGS HAVE_POSIX_SIGNALS MSGFMT MSGMERGE XGETTEXT localedir TCLSH TCL_CONFIG_SH TCL_INCLUDE_SPEC TCL_LIB_FILE TCL_LIBS TCL_LIB_SPEC TCL_SHARED_BUILD TCL_SHLIB_LD_LIBS NSGMLS JADE have_docbook DOCBOOKSTYLE COLLATEINDEX SGMLSPL vpath_build LTLIBOBJS'
ac_subst_files=''
# Initialize some variables set by options.
@@ -863,6 +863,7 @@
--enable-nls[=LANGUAGES] enable Native Language Support
--disable-shareddo not build shared libraries
--disable-rpath do not embed shared library search path in executables
+ --enable-rpath_sl embed shared library search path in dynamic shared libraries
--disable-spinlocks do not use spinlocks
--enable-debug build with debugging symbols (-g)
--enable-depend turn on automatic dependency tracking
@@ -1875,6 +1876,32 @@
+
+# Check whether --enable-rpath_sl or --disable-rpath_sl was given.
+if test "${enable_rpath_sl+set}" = set; then
+ enableval="$enable_rpath_sl"
+
+ case $enableval in
+yes)
+ :
+ ;;
+no)
+ :
+ ;;
+*)
+ { { echo "$as_me:$LINENO: error: no argument expected for --enable-rpath_sl option" >&5
+echo "$as_me: error: no argument expected for --enable-rpath_sl option" >&2;}
+ { (exit 1); exit 1; }; }
+ ;;
+ esac
+
+else
+ enable_rpath_sl=no
+
+fi;
+
+
+
#
# Spinlocks
#
@@ -3358,6 +3385,9 @@
# LIBRARY_DIRS comes from command line, SRCH_LIB from template file.
for dir in $LIBRARY_DIRS $SRCH_LIB; do
if test -d "$dir"; then
+if test "$enable_rpath_sl" = yes; then
+ LIBDIRS="$LIBDIRS -Wl,-R$dir"
+fi
Re: [BUGS] BUG #2170: --rpath option is skipping shared libs
Lee Thompson <[EMAIL PROTECTED]> writes: > Better version of patch. Only kicks in when asked for > with --enable-rpath_sl You still haven't explained why such a change is needed. We're unlikely to accept a patch without explanation, especially given that the existing build system works fine on all the platforms we support. A good way of making such a case is to write the documentation addition that this patch is lacking, explaining when and why people should use this configure switch. BTW, submitting patches against the configure script is useless, as that is a derived file. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #2260: PGCrypto Memory Problem
On Wed, Feb 15, 2006 at 01:43:18PM -0500, Tom Lane wrote: > Michael Fuhr <[EMAIL PROTECTED]> writes: > > I can reproduce this in 8.1.3 on FreeBSD 6.0 and Solaris 9. Here's > > a standalone test case: > > > SELECT crypt(x::text, '$1$salt') FROM generate_series(1, 500) AS g(x); > > Interesting, because I see no leak with this example on Fedora 4 or > HPUX. Platform dependency is sounding more and more likely. Did you test OpenSSL builds? Both of my systems are built with OpenSSL and that causes pgcrypto to use different code in some places (e.g., px_find_digest() in internal.c and openssl.c). I'll build and test a non-OpenSSL version when I get a chance. -- Michael Fuhr ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2260: PGCrypto Memory Problem
Michael Fuhr <[EMAIL PROTECTED]> writes: > I can reproduce this in 8.1.3 on FreeBSD 6.0 and Solaris 9. Here's > a standalone test case: > SELECT crypt(x::text, '$1$salt') FROM generate_series(1, 500) AS g(x); Interesting, because I see no leak with this example on Fedora 4 or HPUX. Platform dependency is sounding more and more likely. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2259: never ending select from selects
"Michal Dvoracek" <[EMAIL PROTECTED]> writes: > this query runs very long time - after hour i cancelled it. The EXPLAIN output is just about unreadable as you've posted it --- could you fix that and repost? Also please provide EXPLAIN ANALYZE output for all the cases that do finish in a reasonable amount of time, especially the one where you made temporary tables. Also, what are the table schemas (particularly, what indexes do they have)? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2260: PGCrypto Memory Problem
"Daniel Blaisdell" <[EMAIL PROTECTED]> writes:
> Table Setup:
> employeeid integer
> salt text
> md5password text
> Problem Query:
> select * from table where md5password = crypt('password',salt)
I tried this with dummy data and couldn't see any memory leak, using
Fedora Core 4 and CVS-tip postgres (but there've been no recent changes
in pgcrypto that would affect this).
I suspect you may have a memory leak in Gentoo's implementation of
crypt(). Another possible theory is that it's data-dependent, in which
case you need to show some sample data that triggers it.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] BUG #2260: PGCrypto Memory Problem
On Tue, Feb 14, 2006 at 05:28:25PM +, Daniel Blaisdell wrote:
> Problem Query:
> select * from table where md5password = crypt('password',salt)
>
> The first time this query is run, I see the postgres process bump up to 8MB
> of ram from where it initializes.
>
> On subsequent issues of the same query the postgres's process memory
> footprint grows each time.
I can reproduce this in 8.1.3 on FreeBSD 6.0 and Solaris 9. Here's
a standalone test case:
SELECT crypt(x::text, '$1$salt') FROM generate_series(1, 500) AS g(x);
Running the query with 'salt' instead of '$1$salt' doesn't exhibit
a memory leak, not even with more iterations from generate_series.
--
Michael Fuhr
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2261: ILIKE seems to be buggy on koi8 input
"Evgeny Gridasov" <[EMAIL PROTECTED]> writes: > my terminal is RU_ru.KOI8-R, > template1's encoding is UTF8. > ILIKE seems to be buggy when comparing russian strings, > while UPPER/LOWER works OK. I'll bet that the database's locale setting is expecting some encoding other than UTF8 :-(. You need to have compatible locale and encoding settings inside the database. You didn't say exactly what the database LC_COLLATE value is, but if it's RU_ru.KOI8-R, that definitely does not match UTF8. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #2263: corrupted pgstat.stat file
"" <[EMAIL PROTECTED]> writes: > I upgraded from 8.1.2 to 8.1.3 without dumping (was not required). After > starting I got this error in the logs: > LOG: corrupted pgstat.stat file > What should I do? Ignore it. We changed the format of the pgstat file between 8.1.2 and 8.1.3. 2006-01-18 15:35 tgl * src/: backend/commands/vacuum.c, backend/postmaster/autovacuum.c, backend/postmaster/pgstat.c, backend/storage/smgr/smgr.c, include/pgstat.h (REL8_1_STABLE): Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2246: Bad malloc interactions: ecpg, openssl
Andrew Klosterman <[EMAIL PROTECTED]> writes: > With the debug binaries, I was able to step through the program and get to > what appears to be the function where it bails: line 1166 of > postgresql-8.1.0/src/interfaces/libpq/fe-secure.c where SSL_free() is > called. BTW, is the address that glibc says is corrupted consistent from run to run? If so, you could narrow down the problem pretty quickly by setting a hardware watchpoint on that address with gdb. Any hits that are not from the malloc subroutines are probably the source of the problem. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #2261: ILIKE seems to be buggy on koi8 input
The following bug has been logged online:
Bug reference: 2261
Logged by: Evgeny Gridasov
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.2
Operating system: Debian Linux
Description:ILIKE seems to be buggy on koi8 input
Details:
my terminal is RU_ru.KOI8-R,
template1's encoding is UTF8.
ILIKE seems to be buggy when comparing russian strings,
while UPPER/LOWER works OK.
template1=# \encoding koi8;
try to get uppercase of some russian letters:
template1=# select upper('ÑÑва');
upper
---
ФЫÐÐ
(1 row)
result is OK!
next, try to compare uppercase and lowercase using
ILIKE:
template1=# select true where 'ÑÑва' ilike 'ФЫÐÐ';
bool
--
(0 rows)
OOPS! Nothing happened. But why?
try the same but with latin charset letters:
template1=# select true where 'asdf' ilike 'ASDF';
bool
--
t
(1 row)
Try to compare lowercase with lowercase (russian):
template1=# select true where 'ÑÑва' ilike 'ÑÑва';
bool
--
t
(1 row)
it works.
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2246: Bad malloc interactions: ecpg, openssl
On Mon, 13 Feb 2006, Stephen Frost wrote: > Hmm, alright, well, this is at least not the fault of the patch of mine > which was included in Debian's 8.1.2-2 Postgres release. :) You might > try compiling some debs with debugging enabled. This is (reasonably) > straight-forward: > > (as root:) > aptitude install build-essential debhelper cdbs bison perl libperl-dev \ > tk8.4-dev flex libreadline5-dev libssl-dev zlib1g-dev \ > libpam0g-dev libxml2-dev libkrb5-dev libxslt1-dev python-dev \ > gettext bzip2 fakeroot > (as user:) > apt-get source postgresql-8.1 > cd postgresql-8.1-8.1.0 > export DEB_BUILD_OPTIONS="nostrip" > dpkg-buildpackage -uc -us -rfakeroot > > Should produce .debs in the parent directory which have debugging > information. Another useful build option is "noopt", ie: > export DEB_BUILD_OPTIONS="nostrip noopt", though that could make the > error go disappear. It'd be terribly nice if you could do this and > provide a gdb backtrace with debugging... :) > > Thanks, > > Stephen Alright, I have built a system with the symbols left into the binaries. It still crashes with the "corrupted double-linked list" error. Running with ElectricFence the backtrace I get is: Electric Fence 2.1 Copyright (C) 1987-1998 Bruce Perens. ElectricFence Aborting: Allocating 0 bytes, probably a bug. Program received signal SIGILL, Illegal instruction. [Switching to Thread 16384 (LWP 1895)] 0x401c4851 in kill () from /lib/libc.so.6 (gdb) bt #0 0x401c4851 in kill () from /lib/libc.so.6 #1 0x40037dd5 in EF_Abort () from /usr/lib/libefence.so.0 #2 0x40037823 in memalign () from /usr/lib/libefence.so.0 #3 0x400379ad in malloc () from /usr/lib/libefence.so.0 #4 0x40037a10 in calloc () from /usr/lib/libefence.so.0 #5 0x404a282f in krb5_set_default_tgs_ktypes () from /usr/lib/libkrb5.so.3 #6 0x402c9b26 in pg_krb5_init (PQerrormsg=0x0) at fe-auth.c:119 #7 0x402ca304 in pg_fe_getauthname (PQerrormsg=0xb29c "l\031") at fe-auth.c:176 #8 0x402cc861 in conninfo_parse (conninfo=, errorMessage=0x4057afe8) at fe-connect.c:2719 #9 0x402cc983 in connectOptions1 (conn=0x4057acdc, conninfo=0x0) at fe-connect.c:362 #10 0x402cda11 in PQsetdbLogin (pghost=0x40574ffc "nc3", pgport=0x0, pgoptions=0x0, pgtty=0x0, dbName=0x40576ff8 "andrew5", login=0xbc31 "andrew5", pwd=0xbc3c "testbed") at fe-connect.c:568 #11 0x40030fe7 in ECPGconnect (lineno=191, c=0, name=0xbc22 "[EMAIL PROTECTED]", user=0xbc31 "andrew5", passwd=0x0, connection_name=0xb8b0 "CorrectnessCheck", autocommit=0) at connect.c:452 #12 0x08049ecb in DBConnect (arg_connection=0xb964 "CorrectnessCheck") at client_test.pgcc:191 #13 0x0804a14f in DoCorrectnessChecks () at client_test.pgcc:231 #14 0x0804aa08 in main (argc=9, argv=0xba74) at client_test.pgcc:526 Again, it is showing a bad malloc in what appears to be some code using kerberos. But there's nothing in my setup that I can think of right now that should induce a connection to be set up using kerberos. --Andrew J. Klosterman [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2246: Bad malloc interactions: ecpg, openssl
> > Tracking down exactly what's tickling the problem in this case could be > > tricky... > > Yeah :-(. If you aren't able to narrow it further by yourself, please > try to put together a self-contained test case. > > regards, tom lane Well, my attempt last night at putting together a test case that manifests the error that I encountered was a total failure! The test code executes flawlessly: no abnormal termination. There must be something different between the two programs. But my original is considerably more complex. I'll pursue other options for debugging before returning to figuring out the difference between the "real" code and the "test-case" code. --Andrew J. Klosterman [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] BUG #2260: PGCrypto Memory Problem
The following bug has been logged online:
Bug reference: 2260
Logged by: Daniel Blaisdell
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.2
Operating system: Gentoo Linux K:2.6.9
Description:PGCrypto Memory Problem
Details:
Prereq:
PGCrypto
Table Setup:
employeeid integer
salt text
md5password text
Problem Query:
select * from table where md5password = crypt('password',salt)
The first time this query is run, I see the postgres process bump up to 8MB
of ram from where it initializes.
On subsequent issues of the same query the postgres's process memory
footprint grows each time.
Initial Memory Usage (from Top)
13463 postgres 17 0 17556 4716 15m S 0.0 0.5 0:00.00 postgres:
postgres fh_dev [local] idle
Initial RSS: 4716
After 1st Query Run:
13570 postgres 16 0 91120 78m 15m S 0.0 8.8 0:01.22 postgres:
postgres fh_dev [local] idle
RSS: 78M
After 2nd Query Run:
13570 postgres 16 0 160m 149m 15m S 0.0 17.0 0:02.60 postgres:
postgres fh_dev [local] idle
RSS: 149M
After 3rd Query Run:
13570 postgres 16 0 232m 221m 15m S 30.9 25.1 0:03.83 postgres:
postgres fh_dev [local] idle
RSS: 232M
4th Query Run:
RSS: 293M
And so on and so forth until all swap space is eaten up.
Hope someone knows what's going on here, i'd love to be able to use the
pgcrypto contribs in production.
-Daniel
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[BUGS] BUG #2262: WHERE-clause comparisons wrong
The following bug has been logged online: Bug reference: 2262 Logged by: Richard Baverstock Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1 Operating system: Windows XP Pro Description:WHERE-clause comparisons wrong Details: History: Imported data from an 8.0 to 8.1 server. The 8.0 server was set to use whatever the default encoding was on win32; the 8.1 server is set to use utf8. Import using a dump from the 8.0 server went fine. Problem: When querying the database, any requirements for "WHERE" that involve comparing strings with spaces or dashes/hyphens return false, when they should be true. For example; assuming a table called inventory has a column named "Number" (varchar), and a row has the value 'ABC 123' for the number, the following returns the correct row: select "Number" from "inventory" where "Number" LIKE 'ABC%'; however, the following two queries return no rows: select "Number" from "inventory" where "NUMBER" LIKE 'ABC %'; select "Number" from "inventory" where "Number" = 'ABC 123'; IF however, the Number being searched for was not imported from the 8.0 database, everything is fine. The space as returned by the successful query is the correct hex value (0x20). ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] BUG #2259: never ending select from selects
The following bug has been logged online:
Bug reference: 2259
Logged by: Michal Dvoracek
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.2
Operating system: Debian testing
Description:never ending select from selects
Details:
Hello,
this query runs very long time - after hour i cancelled it.
SELECT * FROM (SELECT
d.zamestnanci_id,d.prostredky_id,d.zacatek,d.delka,p.budovy_id FROM diar AS
d,prostredky AS p,budovy AS b,X_zamestnanci_skupiny AS x WHERE
x.skupinyzamestnancu_id=7 AND Â x.zamestnanci_id=d.zamestnanci_id AND
d.ukony_id=0 AND d.zamestnanci_id=777 AND d.zacatek>=1139927357 AND
d.delka>=1800 AND d.prostredky_id=p.id AND p.vhodnost_planovani=0 AND
p.budovy_id=b.id AND b.mesto_id=12702) AS d0,(SELECT
d.zamestnanci_id,d.prostredky_id,d.zacatek,d.delka,p.budovy_id FROM diar AS
d,prostredky AS p,budovy AS b,X_zamestnanci_skupiny AS x WHERE
x.skupinyzamestnancu_id=5 AND x.zamestnanci_id=d.zamestnanci_id AND
d.ukony_id=0 AND d.zamestnanci_id=19 AND d.zacatek>=1139927357 AND
d.delka>=1800 AND d.prostredky_id=p.id AND p.vhodnost_planovani=0 AND
p.budovy_id=b.id AND b.mesto_id=12702) AS d1,(SELECT
d.zamestnanci_id,d.prostredky_id,d.zacatek,d.delka,p.budovy_id FROM diar AS
d,prostredky AS p,budovy AS b,X_zamestnanci_skupiny AS x WHERE
x.skupinyzamestnancu_id=5 AND x.zamestnanci_id=d.zamestnanci_id AND
d.ukony_id=0 AND d.zamestnanci_id=19 AND d.zacatek>=1139927357 AND
d.delka>=1800 AND d.prostredky_id=p.id AND p.vhodnost_planovani=0 AND
p.budovy_id=b.id AND b.mesto_id=12702) AS d2,(SELECT
d.zamestnanci_id,d.prostredky_id,d.zacatek,d.delka,p.budovy_id FROM diar AS
d,prostredky AS p,budovy AS b,X_zamestnanci_skupiny AS x WHERE
x.skupinyzamestnancu_id=5 AND x.zamestnanci_id=d.zamestnanci_id AND
d.ukony_id=0 AND d.zamestnanci_id=19 AND d.zacatek>=1139927357 AND
d.delka>=1800 AND d.prostredky_id=p.id AND p.vhodnost_planovani=0 AND
p.budovy_id=b.id AND b.mesto_id=12702) AS d3 WHERE Â
d1.zacatek<=(d0.zacatek+-257400) AND
(d1.zacatek+d1.delka)>=(d0.zacatek+-255600) AND d0.budovy_id=d1.budovy_id
AND
d2.zacatek<=(d0.zacatek+-255600) AND
(d2.zacatek+d2.delka)>=(d0.zacatek+-253800) AND d0.budovy_id=d2.budovy_id
AND
d3.zacatek<=(d0.zacatek+-253800) AND
(d3.zacatek+d3.delka)>=(d0.zacatek+-252000) AND d0.budovy_id=d3.budovy_id
ORDER BY d0.zacatek LIMIT 5;
QUERY PLAN
---
-
 Limit  (cost=3227.94..3227.94 rows=1 width=80)
  ->  Sort  (cost=3227.94..3227.94 rows=1 width=80)
     Sort Key: d.zacatek
     ->  Nested Loop  (cost=1167.30..3227.93 rows=1 width=80)
        ->  Nested Loop  (cost=1167.30..3222.16 rows=1
width=80)
           Join Filter: (("outer".zacatek <=
("inner".zacatek +
-253800)) AND (("outer".zacatek + "outer".delka) >= ("inner".zacatek +
-252000)) AND ("outer".zacatek <= ("inner".zacatek + -255600)) AND
(("outer".zacatek + "outer".delka) >= (
"inner".zacatek + -253800)) AND ("outer".zacatek <= ("inner".zacatek +
-257400)) AND (("outer".zacatek + "outer".delka) >= ("inner".zacatek +
-255600)))
           ->  Nested Loop  (cost=1144.82..3195.61
rows=1 width=68)
              Join Filter: ("outer".budovy_id =
"inner".budovy_id)
              ->  Nested Loop
 (cost=1101.76..2136.66 rows=1
width=60)
                 ->  Nested Loop
 (cost=1101.76..2132.29
rows=1 width=52)
                    ->  Hash Join
 (cost=1101.76..2117.51
rows=3 width=48)
                       Hash
Cond: ("outer".budovy_id =
"inner".budovy_id)
                       ->
 Nested Loop Â
(cost=43.05..1058.65 rows=24 width=24)
                        Â
 ->  Index Scan using
i_x_zamestnanci_skupiny_zam_id on x_zamestnanci_skupiny x  (cost=0.00..5.76
rows=1 width=4)
                        Â
    Index Cond: (19 =
zamestnanci_id)
                        Â
    Filter:
(skupinyzamestnancu_id = 5)
                        Â
 ->  Hash Join Â
(cost=43.05..1052.65 rows=24 width=24)
                        Â
    Hash Cond:
("outer".prostredky_id = "inner".id)
            Â
Re: [BUGS] BUG #2246: Bad malloc interactions: ecpg, openssl
> We may be spending too much time on this one point --- as long as > Kerberos isn't *writing* into the zero-length alloc, there is nothing > illegal immoral or fattening about malloc(0). Can you get ElectricFence > to not abort right here but continue on to the real problem? > > regards, tom lane Doing a "man efence" lets me know that setting the EF_ALLOW_MALLOC_0 environment variable ought to let the program continue... I'll check into that right now! --Andrew J. Klosterman [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2246: Bad malloc interactions: ecpg, openssl
On Tue, 14 Feb 2006, Stephen Frost wrote: > It's kind of a chicken-and-egg here because the backend decides what > authentication mechanism to ask for based off the username (at least in > part) through pg_hba.conf, so you can't find out the authentication > method until you know the username so all methods to find the username > have to be exhausted. You could avoid this by explicitly passing > 'user=' into the connection parameters though... Would be interesting > to know what happens then... When asking about "explicitly passing 'user=' in to the connection parameters" do you mean that the EXEC SQL CONNECT line that ecpg parses should specify a username? My code is using the following statement when making a remote connection that uses SSL. EXEC SQL CONNECT TO :l_target AS :l_connection USER :l_user IDENTIFIED BY :l_passwd; The target machine (hosting the database) has "ssl=on" in postgresql.conf and in its pg_hba.conf (snippet below) a line for the client machine from which I am making the connection that specifies an SSL connection should be made. # TYPE DATABASEUSERCIDR-ADDRESS METHOD hostssl andrew5 andrew5 172.19.130.4/32 pam passwd --Andrew J. Klosterman [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] BUG #2263: corrupted pgstat.stat file
The following bug has been logged online: Bug reference: 2263 Logged by: Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3 Operating system: Linux x86 Description:corrupted pgstat.stat file Details: Hello! I upgraded from 8.1.2 to 8.1.3 without dumping (was not required). After starting I got this error in the logs: LOG: corrupted pgstat.stat file What should I do? Thanks! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2246: Bad malloc interactions: ecpg, openssl
On Tue, 14 Feb 2006, Andrew Klosterman wrote:
> On Mon, 13 Feb 2006, Stephen Frost wrote:
>
> > Hmm, alright, well, this is at least not the fault of the patch of mine
> > which was included in Debian's 8.1.2-2 Postgres release. :) You might
> > try compiling some debs with debugging enabled. This is (reasonably)
> > straight-forward:
> >
> > (as root:)
> > aptitude install build-essential debhelper cdbs bison perl libperl-dev \
> > tk8.4-dev flex libreadline5-dev libssl-dev zlib1g-dev \
> > libpam0g-dev libxml2-dev libkrb5-dev libxslt1-dev python-dev \
> > gettext bzip2 fakeroot
> > (as user:)
> > apt-get source postgresql-8.1
> > cd postgresql-8.1-8.1.0
> > export DEB_BUILD_OPTIONS="nostrip"
> > dpkg-buildpackage -uc -us -rfakeroot
> >
> > Should produce .debs in the parent directory which have debugging
> > information. Another useful build option is "noopt", ie:
> > export DEB_BUILD_OPTIONS="nostrip noopt", though that could make the
> > error go disappear. It'd be terribly nice if you could do this and
> > provide a gdb backtrace with debugging... :)
> >
> > Thanks,
> >
> > Stephen
>
> Alright, I have built a system with the symbols left into the binaries.
>
> It still crashes with the "corrupted double-linked list" error.
>
> Running with ElectricFence the backtrace I get is:
>
> Electric Fence 2.1 Copyright (C) 1987-1998 Bruce Perens.
>
> ElectricFence Aborting: Allocating 0 bytes, probably a bug.
>
> Program received signal SIGILL, Illegal instruction.
> [Switching to Thread 16384 (LWP 1895)]
> 0x401c4851 in kill () from /lib/libc.so.6
> (gdb) bt
> #0 0x401c4851 in kill () from /lib/libc.so.6
> #1 0x40037dd5 in EF_Abort () from /usr/lib/libefence.so.0
> #2 0x40037823 in memalign () from /usr/lib/libefence.so.0
> #3 0x400379ad in malloc () from /usr/lib/libefence.so.0
> #4 0x40037a10 in calloc () from /usr/lib/libefence.so.0
> #5 0x404a282f in krb5_set_default_tgs_ktypes () from /usr/lib/libkrb5.so.3
> #6 0x402c9b26 in pg_krb5_init (PQerrormsg=0x0) at fe-auth.c:119
> #7 0x402ca304 in pg_fe_getauthname (PQerrormsg=0xb29c "l\031")
> at fe-auth.c:176
> #8 0x402cc861 in conninfo_parse (conninfo=,
> errorMessage=0x4057afe8) at fe-connect.c:2719
> #9 0x402cc983 in connectOptions1 (conn=0x4057acdc, conninfo=0x0)
> at fe-connect.c:362
> #10 0x402cda11 in PQsetdbLogin (pghost=0x40574ffc "nc3", pgport=0x0,
> pgoptions=0x0, pgtty=0x0, dbName=0x40576ff8 "andrew5",
> login=0xbc31 "andrew5", pwd=0xbc3c "testbed") at fe-connect.c:568
> #11 0x40030fe7 in ECPGconnect (lineno=191, c=0, name=0xbc22 "[EMAIL
> PROTECTED]",
> user=0xbc31 "andrew5", passwd=0x0,
> connection_name=0xb8b0 "CorrectnessCheck", autocommit=0)
> at connect.c:452
> #12 0x08049ecb in DBConnect (arg_connection=0xb964 "CorrectnessCheck")
> at client_test.pgcc:191
> #13 0x0804a14f in DoCorrectnessChecks () at client_test.pgcc:231
> #14 0x0804aa08 in main (argc=9, argv=0xba74) at client_test.pgcc:526
>
> Again, it is showing a bad malloc in what appears to be some code using
> kerberos. But there's nothing in my setup that I can think of right now
> that should induce a connection to be set up using kerberos.
>
> --Andrew J. Klosterman
> [EMAIL PROTECTED]
With the debug binaries, I was able to step through the program and get to
what appears to be the function where it bails: line 1166 of
postgresql-8.1.0/src/interfaces/libpq/fe-secure.c where SSL_free() is
called.
Included below is a copy&paste of my GDB session. Within the function
that calls SSL_free(), being close_SSL(PGconn *conn), I inserted a
breakpoint. The value of *conn is printed out, which will hopefully
assist in any debugging...
(gdb) break fe-secure.c:1162
No source file named fe-secure.c.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (fe-secure.c:1162) pending.
(gdb) set args -t [EMAIL PROTECTED] -u andrew5 -p testbed -i 10
(gdb) run
Starting program:
/.amd/flush/home/andrew5/projects/CVS-controlled/users/andrew5/thesis/code/database/metadata_server/test/client_test
-t [EMAIL PROTECTED] -u andrew5 -p testbed -i 10
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 2103)]
Breakpoint 2 at 0x402d4bc0: file fe-secure.c, line 1162.
Pending breakpoint "fe-secure.c:1162" resolved
[Switching to Thread 16384 (LWP 2103)]
Breakpoint 2, close_SSL (conn=0x8059d00) at fe-secure.c:1162
1162{
Current language: auto; currently c
(gdb) bt
#0 close_SSL (conn=0x8059d00) at fe-secure.c:1162
#1 0x402c6938 in closePGconn (conn=0x8059d00) at fe-connect.c:1976
#2 0x402c6a55 in PQfinish (conn=0x8059d00) at fe-connect.c:2021
#3 0x400308f9 in ecpg_finish (act=0x8059ca8) at connect.c:122
#4 0x40031707 in ECPGdisconnect (lineno=134585600,
connection_name=0xb8a8 "CorrectnessCheck") at connect.c:540
#5 0x0804a036 in DBDisconnect (arg_connection=0xb954
"CorrectnessCheck")
at client_test.pgcc:218
#6 0x0804a58a in DoCorr
[BUGS] BUG #2264: bad work with cyrillic encoding
The following bug has been logged online:
Bug reference: 2264
Logged by: Alex Kostyshin
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.x
Operating system: Windows XP/SP2, Windows XP x64
Description:bad work with cyrillic encoding
Details:
1. Wrong sorting order: not A,a,B,b, etc for cyrillic texts, but
A,B,...,a,b..
String functions do not work with cyrillic arguments, for example:
Latin:
Select lower('Tom')
lower
tom
1 record(s) selected [Fetch MetaData: 31/ms] [Fetch Data: 0/ms]
Cyrillic:
Select lower('ÐлекÑ')
lower
ÐлекÑ
1 record(s) selected [Fetch MetaData: 0/ms] [Fetch Data: 0/ms]
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] BUG #2246: Bad malloc interactions: ecpg, openssl
On Tue, 14 Feb 2006, Andrew Klosterman wrote: > > We may be spending too much time on this one point --- as long as > > Kerberos isn't *writing* into the zero-length alloc, there is nothing > > illegal immoral or fattening about malloc(0). Can you get ElectricFence > > to not abort right here but continue on to the real problem? > > > > regards, tom lane > > Doing a "man efence" lets me know that setting the EF_ALLOW_MALLOC_0 > environment variable ought to let the program continue... I'll check into > that right now! > > > --Andrew J. Klosterman > [EMAIL PROTECTED] Well, when ElectricFence is allowed to ignore malloc() of zero bytes, my program runs like a champ! Might be associated with the replacement malloc() that it installs to check for bugs, though. (back to digging some more...) --Andrew J. Klosterman [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #2246: Bad malloc interactions: ecpg, openssl
On Tue, 14 Feb 2006, Jens-Wolfhard Schicke wrote: > --On Montag, Februar 13, 2006 21:25:30 -0500 Stephen Frost > <[EMAIL PROTECTED]> wrote: > > > * Andrew Klosterman ([EMAIL PROTECTED]) wrote: > >> > Seems kind of unlikely... What exact (.deb) versions of libpq and > >> > Postgres are you using? You originally posted w/ 8.1.0 but perhaps on > >> > the client you had something more recent? > > aptitude install build-essential debhelper cdbs bison perl libperl-dev \ > > tk8.4-dev flex libreadline5-dev libssl-dev zlib1g-dev \ > > libpam0g-dev libxml2-dev libkrb5-dev libxslt1-dev python-dev \ > > gettext bzip2 fakeroot > You might want to add valgrind to this list. It analyzes code on assembler > basis and does a lot of memory checking / undefined variables checking > while the program runs. Fixed all SIGSEGV I ever encoutered which were not > infinite recursions. > > Mit freundlichem Gru? > Jens Schicke I tried valgrind this morning. It detected problems in the depths of the code behind ECPGconnect() down through SSL_read() and inflate(). Also, there was trouble reported behind ECPGconnect() -> PQsetdbLogin() -> pqGetpwuid() -> getpwuid_r() -> _dl_open() -> into the depths of /lib/ld-2.3.5.so. Valgrind got so upset at the number of errors it found that it gave up. Nothing bad seemed to show up in the code that I wrote. But, while running under valgrind, the original program that manifests the error condition runs just fine and to completion (maybe the errors are just ignored in valgrind's replacement version of malloc as they are with the MALLOC_CHECK_ environment variable set). I'm moving on to try building the binaries without removing the symbols. Hopefully that will give more useful information... --Andrew J. Klosterman [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: explain analyze is your friend
