From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | "David E(dot) Wheeler" <david(at)justatheory(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Advisory Lock BIGINT Values |
Date: | 2012-08-28 03:56:32 |
Message-ID: | 17791.1346126192@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2012-08-28 04:10:33 | Re: wal_buffers |
Previous Message | Jeff Davis | 2012-08-28 03:21:38 | Minor comment fixups |