From: | Russell Smith <mr-russ(at)pws(dot)com(dot)au> |
---|---|
To: | |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: VACUUM and transactions in different databases |
Date: | 2006-12-07 23:04:48 |
Message-ID: | 45789E10.7030300@pws.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Cornelia Boenigk wrote:
> Hi Ragnar
>
>> could not duplicate this.
>
> I also cannot reproduce the hanging VACUUM FULL. The problem remains
> thet the dead tuples cannot be vemoved.
>
[snip]
I am interested in this. As one database cannot talk to another database
in a transactional way a long running transaction in one database should
not effect the vacuuming of another database. From my limited
understanding VACUUM takes the lowest open transaction number and only
cleans up transactions with TID's lower than that. The reason I believe
that it has to use cluster wide is because the shared catalogs might be
effected. Do shared catalogs follow MVCC or ACID strictly? I don't
know, but I assume they don't follow both given my reading of the list.
So if shared catalogs are the problem, what happens if you just vacuum
the relevant table public.dummy1 and not the whole database, does the
vacuum remove all the tuples that are dead?
Is it possible to add logic for lazy vacuum that takes the lowest TID in
our database when not vacuuming shared catalogs? This may already be
the case, I don't know. Just putting forward suggestions.
Russell Smith
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2006-12-07 23:06:05 | Re: Restore database from files (not dump files)? |
Previous Message | Alan Hodgson | 2006-12-07 22:52:11 | Re: loading data, creating indexes, clustering, vacuum... |