Re: [BUGS] PostgreSQL 7.3.3 with pgcrypto on FreeBSD 5.1

2003-07-22 Thread Sean Chittenden
> Please describe a way to repeat the problem.   Please try to provide a
> concise reproducible example, if at all possible: 
> --
> 
> testdb=# SELECT crypt('lalalal',gen_salt('md5'));
> 
>   server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
>   The connection to the server was lost. Attempting reset: Failed.
> 
> 
> 
> LOG:  ReadRecord: record with zero length at 0/18BDEA8
> LOG:  redo is not required
> LOG:  database system is ready
> LOG:  server process (pid 21460) was terminated by signal 11
> LOG:  terminating any other active server processes
> LOG:  all server processes terminated; reinitializing shared memory and semaphores
> LOG:  database system was interrupted at 2003-07-21 11:44:47 EEST
> LOG:  checkpoint record is at 0/18BDEA8
> LOG:  redo record is at 0/18BDEA8; undo record is at 0/0; shutdown TRUE
> LOG:  next transaction id: 996; next oid: 98896
> LOG:  database system was not properly shut down; automatic recovery in progress
> FATAL:  The database system is starting up
> 

FWIW, I can confirm this, but I don't think it's a FreeBSD specific
problem given that the backend dies inside of an OpenSSL routine.

#0  0x2864ae9c in EVP_DigestUpdate () from /usr/lib/libcrypto.so.3
#1  0x28576a90 in px_find_cipher () from /usr/local/lib/postgresql/pgcrypto.so
#2  0x2857c584 in px_crypt_md5 () from /usr/local/lib/postgresql/pgcrypto.so
#3  0x2857efa4 in px_gen_salt () from /usr/local/lib/postgresql/pgcrypto.so
#4  0x2857ee1f in px_crypt () from /usr/local/lib/postgresql/pgcrypto.so
#5  0x2857d2be in pg_crypt () from /usr/local/lib/postgresql/pgcrypto.so
#6  0x0811acb6 in ExecMakeFunctionResult ()
#7  0x0811b7db in ExecEvalExpr ()
#8  0x0811e794 in ExecProject ()
#9  0x0811cb7a in ExecProject ()
#10 0x081282a5 in ExecResult ()
#11 0x0811a0e5 in ExecProcNode ()
#12 0x0811952c in ExecEndPlan ()
#13 0x081188b8 in ExecutorRun ()
#14 0x0819b703 in PortalRun ()
#15 0x0819b53e in PortalRun ()
#16 0x08199b21 in authdie ()
#17 0x081982fd in PostgresMain ()
#18 0x0816de64 in PostmasterMain ()
#19 0x0816d628 in PostmasterMain ()
#20 0x0816bcc6 in PostmasterMain ()
#21 0x0816b5c7 in PostmasterMain ()
#22 0x0813588b in main ()
#23 0x0806c802 in _start ()

Both crypt() and gen_salt() work independently of each other:

test=# SELECT gen_salt('md5');
  gen_salt
-
 $1$nouzuI/B
(1 row)

test=# SELECT crypt('foo','ba');
 crypt
---
 ba4TuD1iozTxw
(1 row)

:-/ crypt() does die with the salt, '$1$' Not sure why either...

That said, the right work around is to _not_ use gen_salt('md5') when
passing data in to crypt(), instead, use gen_salt('des').  The readme
says its not recommended, but in the same breath, it should recommend
that gen_salt('des') is as weak as crypt() and gen_salt('des')
produces the correct salt for use with crypt().




What's interesting, however, is that I can no longer ctrl+c to get out
of psql after the backend dies.  To kill psql, I have to suspend it,
then kill.

test=# SELECT crypt('lalal',gen_salt('md5'));
The connection to the server was lost. Attempting reset: Failed.
connection pointer is NULL
!>
!>
!>
!>
!>
!>
!>
[1]  + 15252 Suspended psql test pgsql
1:08pm [EMAIL PROTECTED]:databases/postgresql-devel > kill %1
1:08pm [EMAIL PROTECTED]:databases/postgresql-devel >
[1]Terminatedpsql test pgsql


-sc

-- 
Sean Chittenden

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [GENERAL] [BUGS] INSTEAD rule bug?

2003-07-22 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What does the code do now after you changed it?  Fail on the UNION
> query?

Yeah.  You get something about "union can't be conditionally executed"
(I forget the exact wording, but it's comparable to what we say about
NOTIFY under similar circumstances).

regards, tom lane

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

   http://archives.postgresql.org


[BUGS] Bugzilla?

2003-07-22 Thread Boris Folgmann
Hi!

I posted a bug report to this list. Did anybody receive it (subject: Silent
Deadlock)? I wanted to use bugzilla instead but couldn't find a link to it
on www.postgresql.org. Please move it to a prominent place, if you still
use it.

I'm also wondering what happened to news.postgresql.org, because it does
not respond for days know.

cu,
boris



---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [GENERAL] [BUGS] INSTEAD rule bug?

2003-07-22 Thread Bruce Momjian
Tom Lane wrote:
> DeJuan Jackson <[EMAIL PROTECTED]> writes:
> >   Or is it simply any conditional rule using UNION/EXCEPT/INTERSECT/...?
> 
> Yeah, that's about the size of it :-(.  Note though that you could
> probably work around the problem by pushing the UNION etc. down into a
> sub-select:
>   SELECT * FROM (SELECT ... UNION ...) foo;
> 
> At some point we could look at automatically transforming the query in
> that way, but I'm not planning to worry about it now.

What does the code do now after you changed it?  Fail on the UNION
query?

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(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