Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id BED9F475EA4 for ; Tue, 22 Oct 2002 06:47:44 -0400 (EDT) Received: from web80301.mail.yahoo.com (web80301.mail.yahoo.com [66.218.79.17]) by postgresql.org (Postfix) with SMTP id 16331475C26 for ; Tue, 22 Oct 2002 06:47:44 -0400 (EDT) Message-ID: <20021022104746.28403.qmail@web80301.mail.yahoo.com> Received: from [203.87.150.116] by web80301.mail.yahoo.com via HTTP; Tue, 22 Oct 2002 03:47:46 PDT Date: Tue, 22 Oct 2002 03:47:46 -0700 (PDT) From: Ludwig Lim Subject: Re: Locking that will delayed a SELECT To: Tom Lane Cc: PostgreSQL Mailing List In-Reply-To: <17217.1034949478@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200210/272 X-Sequence-Number: 9989 --- Tom Lane wrote: > A simple answer is to have T1 grab an ACCESS > EXCLUSIVE lock on some > table to block T2's progress. If that locks out > third-party > transactions that you'd rather would go through, you > can probably use > a lesser form of lock --- but then both T1 and T2 > will have to cooperate > since each will need to explicitly take a lock. - Is there a possibility of having a lock that similar to a row level ACCESS EXCLUSIVE (i.e. ROW ACCESS EXCLUSIVE lock) in the future release of PostgreSQL? The ACCESS EXCLUSIVE lock also locks the rows not used in T1, making concurrent transactions almost impossible. regards, ludwig __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com