Re: Advisory Lock BIGINT Values - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Advisory Lock BIGINT Values
Date
Msg-id 17791.1346126192@sss.pgh.pa.us
Whole thread Raw
In response to Re: Advisory Lock BIGINT Values  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Advisory Lock BIGINT Values
Re: Advisory Lock BIGINT Values
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> On Fri, Mar  9, 2012 at 04:36:08PM -0800, David E. Wheeler wrote:
>>      A <type>bigint</type> key is displayed with its
>>      high-order half in the <structfield>classid</> column, its low-order half
>>      in the <structfield>objid</> column, and <structfield>objsubid</> equal
>> !    to 1. The original <type>bigint</type> value can be reassembled with the
>> !    expression <literal>(classid::int::bit(64) << 32 |
>> !    objid::int::bit(64))::bigint</literal>. Integer keys are displayed with the
>> !    first key in the
>>      <structfield>classid</> column, the second key in the <structfield>objid</>
>>      column, and <structfield>objsubid</> equal to 2.  The actual meaning of
>>      the keys is up to the user.  Advisory locks are local to each database,

> Thanks, applied.

This formula is not actually correct, as you'd soon find out if you
experimented with values with the high-order bit of the low-order word
set.  (Hint: sign extension.)

The correct formula is both simpler and far more efficient:

(classid::int8 << 32) | objid::int8

This works because oidtoi8 correctly treats the OID value as unsigned.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Minor comment fixups
Next
From: Amit Kapila
Date:
Subject: Re: wal_buffers