Phillip-
Thanks for the explanation of how this works- I'll check it out & let you
know if that is the source of the problem in my case. If it is, perhaps I
can submit a short paragraph for the documentation that will clue people in
if they run into this in the future. I suppose it could be handle
Sean Chittenden <[EMAIL PROTECTED]> writes:
>> Perhaps the problem is that Marko didn't fix the crypt() code in the
>> same way?
> Ah, I think that's _very_ likely the case here... -sc
I updated to openssl 0.9.7b on my HPUX machine, and still do not see any
failure in
regression=# SELECT crypt(
> >> Perhaps the problem is that Marko didn't fix the crypt() code in
> >> the same way?
>
> > Ah, I think that's _very_ likely the case here... -sc
>
> I updated to openssl 0.9.7b on my HPUX machine, and still do not see any
> failure in
>
> regression=# SELECT crypt('lalalal',gen_salt('md5'))
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Possible, but I'm a skeptical of that. FreeBSD's openssl code
> _should_ be stock (unless someone bungled the import) with the
> exception of not including Win32 or other non-FreeBSD related bits.
> crypt() works when salted with only 2 chars, however
> > Possible, but I'm a skeptical of that. FreeBSD's openssl code
> > _should_ be stock (unless someone bungled the import) with the
> > exception of not including Win32 or other non-FreeBSD related
> > bits. crypt() works when salted with only 2 chars, however it
> > shouldn't core with more tha
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Try applying the attached patch and seeing if that lets you reproduce
> the crash.
Hmm. I get *a* crash, maybe not the same one. But there's no
autoconfiguration of this setting in pgcrypto/Makefile, so how would
anyone be using anything but builtin
> > Try applying the attached patch and seeing if that lets you
> > reproduce the crash.
>
> Hmm. I get *a* crash, maybe not the same one. But there's no
> autoconfiguration of this setting in pgcrypto/Makefile, so how would
> anyone be using anything but builtin crypt()?
I patch contrib/pgcryp
Sean Chittenden <[EMAIL PROTECTED]> writes:
> My bet is Pg is smashing OpenSSL's stack when
> passing more than 2 chars as a salt.
I looked at the code a little bit and that doesn't seem to be the case.
On my machine the core dump seems to be because EVP_DigestUpdate is
called with a EVP_MD_CTX t
"Eric Johnson" <[EMAIL PROTECTED]> writes:
> Later in the script when inserting into these tables via stored procedures,
> the full text indexes get created for a and b but not c. It's just empty.
I can't reproduce this in either 7.3 or CVS tip. The index tables seem
to have reasonable numbers o
That's exactly what I meant. I'm getting 0 rows in tb_c_ingredient_fti.
Thank you for looking into this, I'll keep poking around as to what could be
the problem on my end (not really sure, it's a vanilla install).
Thanks again,
Eric
- Original Message -
From: "Tom Lane" <[EMAIL PROTEC
Hello
It is maybe not bug, but I didn't find any warning about this behavior.
select current_date + 1; -- ok
select 1 + current_date; -- not
ERROR: operator does not exist: integer + date
HINT: No operator matches the given name and argument type(s). You may
need to add explicit typecasts.
11 matches
Mail list logo
