[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

[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.pat

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

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 declarati

[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 imp

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

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 no

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