Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 94D0947642C for ; Mon, 28 Oct 2002 13:39:51 -0500 (EST) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 0D528476414 for ; Mon, 28 Oct 2002 13:39:51 -0500 (EST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.5/8.12.5) with ESMTP id g9SIdnhR015714; Mon, 28 Oct 2002 13:39:49 -0500 (EST) To: "Denise Bossarte" Cc: pgsql-sql@postgresql.org Subject: Re: VACUUM and locking In-reply-to: References: Comments: In-reply-to "Denise Bossarte" message dated "Fri, 25 Oct 2002 10:36:07 -0400" Date: Mon, 28 Oct 2002 13:39:49 -0500 Message-ID: <15713.1035830389@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200210/381 X-Sequence-Number: 10098 "Denise Bossarte" writes: > I have looked at the documentation on locking and VACUUM and have found > conflicting reports. > http://www.postgresql.org/idocs/index.php?locking-tables.html states that > VACUUM (without FULL) acquires a ShareUpdateExclusiveLock and VACUUM with > FULL acquires an AcessExclusiveLock. This is correct. > However, the 7.2.1 Appendix A. Release Notes state "Vacuuming no longer > locks tables, thus allowing normal user access during the vacuum. A new > VACUUM FULL command does old-style vacuum by locking the table and shrinking > the on-disk copy of the table. This is an oversimplification, as it says "lock" where it means AccessExclusiveLock. > Additionally, the "Transaction Processing > in Postgres" pdf http://developer.postgresql.org/pdf/transactions.pdf only > shows AcessExclusiveLock acquird by VACUUM (full? - not stated) (p. 18). This document is pre-7.2. regards, tom lane