X-Original-To: pgsql-sql@postgresql.org Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 8F3FF475843 for ; Mon, 3 Feb 2003 13:58:58 -0500 (EST) Received: from omta01.mta.everyone.net (sitemail3.everyone.net [216.200.145.37]) by postgresql.org (Postfix) with ESMTP id 77FF0475925 for ; Mon, 3 Feb 2003 13:58:57 -0500 (EST) Received: from sitemail.everyone.net (dsnat [216.200.145.62]) by omta01.mta.everyone.net (Postfix) with ESMTP id 92A2C1C36B9; Mon, 3 Feb 2003 10:58:57 -0800 (PST) Received: by sitemail.everyone.net (Postfix, from userid 99) id 7609D3E7C; Mon, 3 Feb 2003 10:58:57 -0800 (PST) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Date: Mon, 3 Feb 2003 10:58:57 -0800 (PST) From: Jasper Tymesman To: pgsql-sql@postgresql.org Subject: Serialized Transaction Locking Issues Reply-To: jtyme@bboy.com X-Originating-Ip: [66.150.201.162] Message-Id: <20030203185857.7609D3E7C@sitemail.everyone.net> X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200302/127 X-Sequence-Number: 11525 Hello, I'm currently in the midst of working on a serializable transaction which drops indexes on several tables, does a bulk copy, and rebuilds the indexes. Based on what I've read it seemed as though I'd be able to concurrently execute read on queries against these tables, returning results based on the table snapshot from before the serialized transaction began. However, this doesn't work. A simple read-only select query waits until the serialized transaction is finished before returning results. Based on the user documentation, specifically (http://www.postgresql.org/docs/view.php?version=7.3&idoc=1&file=explicit-locking.html#LOCKING-TABLES), it would seem that the only issue in PostgreSQL that could block a simple select call would be an ACCESS EXCLUSIVE lock, which is acquired only by DROP TABLE, ALTER TABLE, and VACUUM FULL, none of which I'm using. In fact, I've noticed this exact behavior with DROP INDEX. Please excuse my futile attempt to outline two concurrent transactions here: testdb=# \d trans_test Table "public.trans_test" Column | Type | Modifiers - -------+--------+----------- val integer Indexes: idx_trans_test btree(val) testdb=# SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL SERIALIZABLE; SET [TRANSACTION 1] BEGIN; BEGIN [TRANSACTION 1] SELECT * FROM trans_test; val - ----- 1 2 [TRANSACTION 2] SELECT * FROM trans_test; val - ----- 1 2 [TRANSACTION 1] DROP INDEX idx_trans_test; DROP INDEX [TRANSACTION 2] SELECT * FROM trans_test; ... (Waiting) [TRANSACTION 1] COMMIT; COMMIT (TRANSACTION 2 returns after COMMIT) val - ----- 1 2 So is this a glitch or am I missing some nuance of a serializable transaction? In either case I'm eager to figure out whats actually going on. Thanks, - -justin _____________________________________________________________ Sign up for FREE email from bboy.com at http://www.bboy.com _____________________________________________________________ Select your own custom email address for FREE! Get you@yourchoice.com w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag