Re: [HACKERS] C based plugins, clocks, locks, and configuration variables

2016-11-09 Thread Craig Ringer
On 10 November 2016 at 07:18, Clifford Hammerschmidt wrote: > > On Tue, Nov 8, 2016 at 2:58 PM, Craig Ringer > wrote: >> >> 2ndQuadrant/bdr > > > That is similar. I'm not clear on the usage of OID for sequence > (`DirectFunctionCall1(nextval_oid, seqoid)`) ... does that imply a lock > around a se

Re: [HACKERS] C based plugins, clocks, locks, and configuration variables

2016-11-09 Thread Craig Ringer
On 10 November 2016 at 07:18, Clifford Hammerschmidt wrote: > > On Tue, Nov 8, 2016 at 2:58 PM, Craig Ringer > wrote: >> >> 2ndQuadrant/bdr > > > That is similar. I'm not clear on the usage of OID for sequence > (`DirectFunctionCall1(nextval_oid, seqoid)`) ... does that imply a lock > around a se

Re: [HACKERS] C based plugins, clocks, locks, and configuration variables

2016-11-09 Thread Clifford Hammerschmidt
On Tue, Nov 8, 2016 at 2:58 PM, Craig Ringer wrote: > 2ndQuadrant/bdr That is similar. I'm not clear on the usage of OID for sequence (` DirectFunctionCall1(nextval_oid, seqoid)`) ... does that imply a lock around a sequence generation? also different is that your sequence doesn't reset on the

Re: [HACKERS] C based plugins, clocks, locks, and configuration variables

2016-11-08 Thread Craig Ringer
On 9 Nov. 2016 02:48, "Clifford Hammerschmidt" wrote: > > Looking closer at the bit math, I screwed it up it should be 64 bits time, 6 bit uuid version, 8 node, 8 seq, and the rest random ... which is 42 bits of random. I'll find the code in a bit. Huh, so that's what you are doing. I just a

Re: [HACKERS] C based plugins, clocks, locks, and configuration variables

2016-11-08 Thread Clifford Hammerschmidt
Looking closer at the bit math, I screwed it up it should be 64 bits time, 6 bit uuid version, 8 node, 8 seq, and the rest random ... which is 42 bits of random. I'll find the code in a bit. -- Clifford Hammerschmidt, P.Eng. On Tue, Nov 8, 2016 at 9:42 AM, Clifford Hammerschmidt < tanglebo..

Re: [HACKERS] C based plugins, clocks, locks, and configuration variables

2016-11-08 Thread Clifford Hammerschmidt
Hi Jim, The values are still globally unique. The odds of a collision are very very low. Two instances with the same node_id generating on the same millisecond (in their local view of time) have a 1:2^34 chance of collision. node_id only repeats every 256 machines in a cluster (assuming you're con

Re: [HACKERS] C based plugins, clocks, locks, and configuration variables

2016-11-08 Thread Jim Nasby
On 11/3/16 7:14 PM, Craig Ringer wrote: 1) getting microseconds (or nanoseconds) from UTC epoch in a plugin GetCurrentIntegerTimestamp() Since you're serializing generation anyway you might want to just forgo the timestamp completely. It's not like the values your generating are globally un

Re: [HACKERS] C based plugins, clocks, locks, and configuration variables

2016-11-07 Thread Craig Ringer
On 8 November 2016 at 07:41, Clifford Hammerschmidt wrote: > Hi Craig, > > Thanks for the pointers; I made a stab at it in: > https://github.com/tanglebones/pg_tuid > > I've no idea if the shmem and lwlock code is correct, or how to test it. It > seems to work (requires loading via the shared_prel

Re: [HACKERS] C based plugins, clocks, locks, and configuration variables

2016-11-03 Thread Craig Ringer
On 4 Nov. 2016 06:05, "Clifford Hammerschmidt" wrote: > > Hi all, > > Apologies in advance if this isn't the right place to be posting this. > > I've started work on a plugin in C (https://github.com/tanglebones/pg_tuid) for generating generally monotonically ascending UUIDs (aka TUIDs), and after