X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 0027411F65D1 for ; Tue, 28 Mar 2006 17:59:51 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 24047-05 for ; Tue, 28 Mar 2006 17:59:47 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from nelson.osl.com (216-21-133-120.ip.van.radiant.net [216.21.133.120]) by postgresql.org (Postfix) with ESMTP id D081511F6558 for ; Tue, 28 Mar 2006 17:59:44 -0400 (AST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: Re: Bitfields always atomic? Other way to store attributes? Date: Tue, 28 Mar 2006 13:59:41 -0800 Message-ID: <144D12D7DD4EC04F99241498BB4EEDCC274CE8@nelson.osl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SQL] Bitfields always atomic? Other way to store attributes? Thread-Index: AcZSsmIaXObNbCI8Spe4LZmeAM86VQAAEpOg From: "Owen Jacobson" To: X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.186 required=5 tests=[AWL=0.186] X-Spam-Score: 0.186 X-Spam-Level: X-Archive-Number: 200603/450 X-Sequence-Number: 24796 TJ O'Donnell wrote: > > If I have two threads modifying the same "bit" field: > > thread1=3D> update table set bf=3Dbf | '01000' > > thread2=3D> update table set bf=3Dbf | '10000' > > Will this operation always be safe (e.g. result in bf=3D'11000')? = Or >=20 > Won't this always result in bf=3D'11xxx', depending on the > original values of bf? Not even. Consider: thread1=3D> update table set bf=3Dbf | '01000' thread3=3D> update table set bf=3Dbf & '10111' thread2=3D> update table set bf=3Dbf | '10000' Now you get bf=3D10xxx. They're thread safe in that all transformations will be applied as-if = serially, so no bit sets or unsets will be lost, but you can't guarantee = that another client won't interfere with the results.