Re: C based plugins, clocks, locks, and configuration variables

From: Craig Ringer <craig(dot)ringer(at)2ndquadrant(dot)com>
To: Clifford Hammerschmidt <tanglebones(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: C based plugins, clocks, locks, and configuration variables
Date: 2016-11-10 00:17:11
Message-ID: CAMsr+YH_NwWJq8uPzdKVi2Wkp48tn3k2dYfCVKW=njx67GwTVw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10 November 2016 at 07:18, Clifford Hammerschmidt
<tanglebones(at)gmail(dot)com> wrote:
>
> On Tue, Nov 8, 2016 at 2:58 PM, Craig Ringer <craig(dot)ringer(at)2ndquadrant(dot)com>
> 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?

No.

> also different is that your sequence doesn't
> reset on the time basis, it ascends and wraps independently of the time.

Right.

> (also, you appear to modulo against the max (2^n-1), not the cardinality
> (2^n), ... should that be an & ... i.e. take SEQUENCE_BITS of 1 ->
> MAX_SEQ_ID of ((1<<1)-1) = 1 -> (seq % 1) = {0} ... not {0,1} as expected;
> (seq & 1) = {0,1} as expected)

Hm. I think you're right there.

> We tried 64-bit values for ids (based on twitter's snowflake), but found
> that time-replay would cause collisions. We had a server have its time
> corrected, going backwards, by an admin; leading to duplicate ids being
> generated, leading to a fun day of debugging and a hard lesson about our
> assumption that time always increases over time.

That's a good point, but it's just going to have to be a documented
limitation. BDR expects you to use NTP and slew time when needed
anyway.

> Using node_id doesn't
> protect against this, since it is the same node creating the colliding ids
> as the original ids. By extending the ids to include a significant amount of
> randomness, and requiring a restart of the db for the time value to move
> backwards (by latching onto the last seen time), we narrow the window for
> collisions to close enough to zero that winning the lottery is far more
> likely (http://preshing.com/20110504/hash-collision-probabilities/ has the
> exact math). We also increase the time scale for id wrap around to long past
> the likely life expectancy of the software we're building today.

It's a good idea. I like what you're doing. I've run into too many
sites that can't or won't use 128-bit generated values though.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2016-11-10 00:19:00 Re: C based plugins, clocks, locks, and configuration variables
Previous Message Robert Haas 2016-11-10 00:03:40 Re: [COMMITTERS] pgsql: pgbench: Allow the transaction log file prefix to be changed.