dbTalk Databases Forums  

[BUGS] problem with libpq7.3.3/encrypted

mailing.database.pgsql-bugs mailing.database.pgsql-bugs


Discuss [BUGS] problem with libpq7.3.3/encrypted in the mailing.database.pgsql-bugs forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Andreas Pflug
 
Posts: n/a

Default [BUGS] problem with libpq7.3.3/encrypted - 07-24-2003 , 03:39 AM






I believe we have a problem with libpq 7.3.3 with encryption. I
currently don't have a 7.3.3/ssl system running, but this has been
reported by Christian Ruediger Bahls, who traced it, and Dave Page.

When running pgAdmin3 over a ssl encrypted connection, it will hang,
even for very small queries with a single result. As soon as
postgresql.conf ssl=false is set, or a 7.3.2 non-encrypting libpq is
used, everything's working fine. There's a complete gdb dump at

http://dmv.math.uni-rostock.de/downloads/gdb_trace.txt

The query string is truncated in that log, it should read like this:

SELECT rw.oid, rw.ev_class, rulename, relname, nspname, description, is_instead, ev_type, ev_action, ev_qual
pg_get_ruledef(rw.oid) AS definition
FROM pg_rewrite rw
JOIN pg_class cl ON cl.oid=rw.ev_class
JOIN pg_namespace nsp ON nsp.oid=cl.relnamespace
LEFT OUTER JOIN pg_description des ON des.objoid=rw.oid
WHERE ev_class = 12345
ORDER BY rulename



Regards,
Andreas


Christian Ruediger Bahls wrote:
Quote:
it could be because of the encryption layer
that postgresql uses ..
i think this is because i use the encrypted layer
an uncomplete stacktrace i have from one
of these runs:
#0 0x407659c4 in read () from /lib/libc.so.6
#1 0x4066db50 in __JCR_LIST__ () from /lib/libpthread.so.0
#2 0x40668f53 in read () from /lib/libpthread.so.0
#3 0x400c31cc in BIO_new_socket () from /usr/lib/libcrypto.so.0.9.7
#4 0x0000000a in ?? ()
#5 0x08aec778 in ?? ()
#6 0x00000005 in ?? ()
#7 0x400c31b6 in BIO_new_socket () from /usr/lib/libcrypto.so.0.9.7
#8 0x4013bc60 in KRB5_AUTHENT_it () from /usr/lib/libcrypto.so.0.9.7
#9 0x08ac3e48 in ?? ()

but still i guess i cant trust these traces
as i got stuff like that as well:
#0 0x40667a71 in __errno_location () from /lib/libpthread.so.0
#1 0x40032430 in ssl3_read () from /usr/lib/libssl.so.0.9.7
#2 0x4004c130 in ssl3_undef_enc_method () from /usr/lib/libssl.so.0.9.7
#3 0xffffffff in ?? ()
#4 0x08ad6b80 in ?? ()
#5 0xbfffee58 in ?? ()
#6 0x4004c130 in ssl3_undef_enc_method () from /usr/lib/libssl.so.0.9.7
#7 0x08b77e38 in ?? ()
#8 0xbfffee18 in ?? ()
#9 0x4003b7ea in SSL_read () from /usr/lib/libssl.so.0.9.7
#10 0x08ac0ed8 in ?? ()
#11 0x08b814f6 in ?? ()
#12 0x00006942 in ?? ()
#13 0x4003b795 in SSL_read () from /usr/lib/libssl.so.0.9.7
#14 0x40153860 in pg_enc2name_tbl () from /usr/lib/libpq.so.3
#15 0xffffffff in ?? ()
#16 0x08ad6b80 in ?? ()
#17 0x40717438 in realloc () from /lib/libc.so.6

And Dave wrote:

Quote:
Interestingly, I've just tried this on Linux, and when viewing
pg_description, the empty edit grid appears with 'Refreshing data,
please wait...' in the task bar and then hangs.

The pg console shows:

LOG: SSL SYSCALL error: EOF detected
LOG: pq_recvbuf: Unexpected EOF on client connection



Regards,
Andreas





---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster




---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match


Reply With Quote
  #2  
Old   
Tom Lane
 
Posts: n/a

Default Re: [BUGS] problem with libpq7.3.3/encrypted - 08-04-2003 , 12:47 PM






Andreas Pflug <pgadmin (AT) pse-consulting (DOT) de> writes:
Quote:
I believe we have a problem with libpq 7.3.3 with encryption. I
currently don't have a 7.3.3/ssl system running, but this has been
reported by Christian Ruediger Bahls, who traced it, and Dave Page.

When running pgAdmin3 over a ssl encrypted connection, it will hang,
even for very small queries with a single result.
I have identified some problems in EOF detection in 7.3.3-and-up with
SSL transport. The behavior I was able to reproduce was (a) incorrect
report of lost connection, when it was only a matter of no data yet,
and (b) bogus error reporting when the connection actually is lost.
I am not sure this explains your problem, but please try the
just-applied patches and see if it helps.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.