On Fri, Jul 08, 2005 at 03:12:59PM -0500, Bruno Wolff III wrote:
> On Fri, Jul 08, 2005 at 23:03:49 +0300,
> Marko Kreen wrote:
> >
> > Well, those OS'es that already have urandom/random, don't need
> > it. And those that don't - I really don't feel responsibility
> > to write one...
>
> But
"Matthew T. O'Connor" writes:
> Tom Lane wrote:
>> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>>> Ok. Do you think it's worth the trouble to have ALTER TABLE commands to
>>> change autovac parameters?
>>
>> I think we'll want them eventually, but I don't mind if 8.1 ships
>> without 'em.
>>
> I
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Ok. Do you think it's worth the trouble to have ALTER TABLE commands to
change autovac parameters?
I think we'll want them eventually, but I don't mind if 8.1 ships
without 'em.
It might be good to ship 8.1 without them
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Fri, Jul 08, 2005 at 03:56:25PM -0400, Tom Lane wrote:
>> pg_autovacuum should only contain user-settable parameters ---
> Ok. Do you think it's worth the trouble to have ALTER TABLE commands to
> change autovac parameters?
I think we'll want them
On Fri, Jul 08, 2005 at 03:56:25PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Here is a second attempt at autovacuum integration.
>
> A few comments:
Excellent, thanks. I'll be working on fixing all these.
> * I strongly disagree with keeping updatable state in a ca
On Fri, Jul 08, 2005 at 23:03:49 +0300,
Marko Kreen wrote:
>
> Well, those OS'es that already have urandom/random, don't need
> it. And those that don't - I really don't feel responsibility
> to write one...
But fortuna is essentially a high quality /dev/urandom. It doesn't make seem to
much
On Fri, Jul 08, 2005 at 02:10:47PM -0500, Bruno Wolff III wrote:
> On Fri, Jul 08, 2005 at 20:54:40 +0300,
> Marko Kreen wrote:
> >
> > The idea is to initially seed Fortuna with randomness from
> > system and later feed SHA1 of user data into it too. Just
> > to keep it from degenerating into
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Here is a second attempt at autovacuum integration.
A few comments:
* I strongly disagree with keeping updatable state in a catalog. In the
first place, that will cause autovac itself to create vacuumable trash.
In the second place, that means you can
On Fri, Jul 08, 2005 at 20:54:40 +0300,
Marko Kreen wrote:
>
> The idea is to initially seed Fortuna with randomness from
> system and later feed SHA1 of user data into it too. Just
> to keep it from degenerating into pure PRNG.
How is fortuna getting entropy?
Wouldn't this be better placed i
This patch adds implementation of SHA2 to pgcrypto.
New hashes: SHA256, SHA384, SHA512.
Code from OpenBSD.
Index: pgsql/contrib/pgcrypto/Makefile
===
*** pgsql.orig/contrib/pgcrypto/Makefile
--- pgsql/contrib/pgcrypto/Makefile
*
Following two patches add Fortuna PRNG to pgcrypto. I think
this is needed to really complete the 'no hand-config' direction
of pgcrypto.
Patch #1 adds implementation of SHA2 hashes (SHA256/384/512).
They are required for Fortuna. As they are replacements
for SHA1 (which was replacement for MD5)
- Add Fortuna PRNG to pgcrypto.
- Move openssl random provider to openssl.c and builtin provider
to internal.c
- Make px_random_bytes use Fortuna, instead of giving error.
- Retarget random.c to aquiring system randomness, for initial seeding
of Fortuna. There is ATM 2 functions for Windows,
[EMAIL PROTECTED] writes:
> That would answer the big question here, but where does it say that?
Also, if you really insist on an authoritative statement, try this text
(from Annex D of the C99 draft standard, "Formal model of sequence
points"):
D.2.2 Function calls
[EMAIL PROTECTED] writes:
> That would answer the big question here, but where does it say that? I
> saw Neil's point that the sequence points before function calls apply for
> the nested calls as well as the outer one, but there is no ordering
> between those "nested-call" sequence points. It's
14 matches
Mail list logo
