Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 98344475843 for ; Wed, 20 Nov 2002 18:12:41 -0500 (EST) Received: from mail1.ihs.com (mail1.ihs.com [170.207.70.222]) by postgresql.org (Postfix) with ESMTP id EF2EE474E61 for ; Wed, 20 Nov 2002 18:12:40 -0500 (EST) Received: from css120.ihs.com (css120.ihs.com [170.207.105.120]) by mail1.ihs.com (8.12.6/8.12.6) with ESMTP id gAKNCDGx029285; Wed, 20 Nov 2002 16:12:13 -0700 (MST) Date: Wed, 20 Nov 2002 16:12:56 -0700 (MST) From: "scott.marlowe" To: Medi Montaseri Cc: Neil Conway , Francisco Reyes , pgsql General List Subject: Re: Closing inactive connections OR user connections limits In-Reply-To: <3DDC110B.3030502@intransa.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailBodyFilter: Message body has not been filtered X-MailScanner: Found to be clean X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200211/877 X-Sequence-Number: 33298 On Wed, 20 Nov 2002, Medi Montaseri wrote: > Its my understanding that vacuum actually removes tuples that have been > updated or deleted. > Sort of like emptying your trash .... whence a tuple has been removed, > no rollback can set the > state back. If you have logically removed a tuple (not vacuumed yet), > then one can rollback, > but if you vacuum then you can not rollback. > > Now suppose transaction A decides to delete some tuples, a vacuum job > comes along and > deletes things (in parallel), trans A decides to rollback....engines who > support parallel > vacuum-ing and transactions such as PG 7.2 better have a way of > protecting themselves > against this.... > > Correct me if ... Yes, you are wrong. Postgresql's vacuuming does NOT free tuples that are still in a transaction, hence a full vacuum will hand waiting for the transaction to complete or roll back. A normal 7.2 vacuum will simply skip the in transaction tuples. For proof, try this: (Note A> and B> are used to represent two different sessions) A> create table test (a text, id int); A> insert into test (a,id) values ('abc',123); A> begin; A> delete from test where id=123; B> vacuum; A> rollback; A> select * from test; a | id -------- abc| 123 Still there. > > Neil Conway wrote: > > >Medi Montaseri writes: > > > > > >>I think from the data integrity point of view, vacuum is more > >>important than vacuum full. > >> > >> > > > >Why would VACUUM have any effect on data integrity, either positive or > >negative? > > > >Cheers, > > > >Neil > > > > > > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >