[PATCH] Implements SPIN_LOCK on ARM
Hi here a little update proposal for ARM architecture. Kind regards. 0001-Implements-SPIN_LOCK-macro-for-ARM.patch Description: Binary data
[PATCH v1] explicit_bzero.c: using explicit_memset on NetBSD
Thanks. Regards. 0001-explicit_bzero.c-uses-explicit_memset-for-NetBSD.patch Description: Binary data
Re: [PATCH] using arc4random for strong randomness matters.
> I dunno, it seems like this is opening us to a new set of portability > hazards (ie, sub-par implementations of arc4random) with not much gain to > show for it. > Hence I reduced to three platforms only. > > IIUC, what this code actually does is reseed itself from /dev/urandom > every so often and work from a PRNG in between. That's not a layer that > we need, because the code on top is already designed to cope with the > foibles of /dev/urandom --- or, to the extent it isn't, that's something > we have to fix anyway. So it seems like having this optionally in place > just reduces what we can assume about the randomness properties of > pg_strong_random output, which doesn't seem like a good idea. > > That I admit these are valid points. Cheers. > regards, tom lane >
Re: [PATCH] using arc4random for strong randomness matters.
Basically the call never fails, always generating high quality random data (especially the implementations based on Chacha* family, RC4 has predictability issues), there is no need of a file descriptor. On 22 November 2017 at 16:06, Tom Lane wrote: > David CARLIER writes: > > I m not against as such that depends of the implementation but I ve seen > in > > quick glance it s RC4 ? > > More generally, why should we bother with an additional implementation? > Is this better than /dev/urandom, and if so why? > > regards, tom lane >
Re: [PATCH] using arc4random for strong randomness matters.
I m not against as such that depends of the implementation but I ve seen in quick glance it s RC4 ? Regards. On 22 November 2017 at 15:37, David Fetter wrote: > On Tue, Nov 21, 2017 at 12:08:46PM +0000, David CARLIER wrote: > > Hello, > > > > This is my first small personal contribution. > > > > Motivation : > > - Using fail-safe, file descriptor free solution on *BSD and Darwin > system > > - Somehow avoiding at the moment FreeBSD as it still uses RC4 (seemingly > > updated to Chacha20 for FreeBSD 12.0 and eventually backported later on). > > - For implementation based on Chacha* it is known to be enough fast for > the > > purpose. > > - make check passes. > > > > Hope it is good. > > > > Thanks in advance. > > This is neat. Apparently, it's useable on Linux with a gizmo called > libbsd. Would it be worth it to test for that library on that > platform? > > Best, > David. > -- > David Fetter http://fetter.org/ > Phone: +1 415 235 3778 > > Remember to vote! > Consider donating to Postgres: http://www.postgresql.org/about/donate >
[PATCH] using arc4random for strong randomness matters.
Hello, This is my first small personal contribution. Motivation : - Using fail-safe, file descriptor free solution on *BSD and Darwin system - Somehow avoiding at the moment FreeBSD as it still uses RC4 (seemingly updated to Chacha20 for FreeBSD 12.0 and eventually backported later on). - For implementation based on Chacha* it is known to be enough fast for the purpose. - make check passes. Hope it is good. Thanks in advance. 0001-Using-arc4random-API-for-strong-randomness-if-availa.patch Description: Binary data
Re: [PATCH] Porting small OpenBSD changes.
I m not against, I would go with your final version too. Thanks ! On 20 November 2017 at 22:36, Tom Lane wrote: > I wrote: > > I still dare to doubt whether you've tested this, because AFAICS > > the operand numbering is wrong. The "r"(lock) operand is number 3 > > given these operand declarations, not number 2. > > Oh, my apologies, scratch that. Evidently I put in the "+m"(*lock) > operand and confused myself about what was what. > > I still think the form I proposed is better style though. > > regards, tom lane >
Re: [PATCH] Porting small OpenBSD changes.
On 20 November 2017 at 18:49, Tom Lane wrote: > David CARLIER writes: > > - Reducing OpenBSD postfgresql maintainer internal changes bookeeping if > > those small changes make sense for the PostgreSQL developers. > > Hm. The s_lock.c change is surely fine if OpenBSD maintainers say it is. > > Not sure about adding Motorola 88K support to s_lock.h ... is anybody > really still interested in that platform? Yes there is :-) > OTOH, we still have M68K > and VAX stanzas in that file, so I suppose it's silly to complain > about 88K. A bigger issue is that I wonder whether that code has > ever been tested: it does not look to me like the __asm__ call is > even syntactically correct. There should be colons in it. > > True :-) corrected. Thanks. > regards, tom lane > 0001-PATCH-1-1-Porting-OpenBSD-internal-changes.patch Description: Binary data
[PATCH] Porting small OpenBSD changes.
Hi, Compilation pass, make check passes. Motivations : - Reducing OpenBSD postfgresql maintainer internal changes bookeeping if those small changes make sense for the PostgreSQL developers. Hope it is good. Thanks in advance. Kind regards. 0001-PATCH-1-1-Porting-OpenBSD-internal-changes.patch Description: Binary data
