Re: Alternative for vacuuming queue-like tables - Mailing list pgsql-general

From Robert Treat
Subject Re: Alternative for vacuuming queue-like tables
Date
Msg-id 200604281352.14380.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: Alternative for vacuuming queue-like tables  (Csaba Nagy <nagy@ecircle-ag.com>)
Responses Re: Alternative for vacuuming queue-like tables  (Csaba Nagy <nagy@ecircle-ag.com>)
List pgsql-general
On Friday 28 April 2006 12:20, Csaba Nagy wrote:
> > There is, I believe, a problem there; there is a scenario where data
> > can get "dropped out from under" those old connections.
> >
> > This has been added to the TODO...
> >
> > http://www.postgresql.org/docs/faqs.TODO.html
> >
> > * Make CLUSTER preserve recently-dead tuples per MVCC requirements
>
> OK, I can see this being a problem in the general case.
>
> However, for my queue table the current behavior is a life-saver. Would
> it be possible to still provide a variant of rebuild which is documented
> to not be MVCC compliant ? Something like: I don't care the old
> transactions which did not touch yet this table to see the old data for
> this table, I want to rebuild it.
>
> I actually don't care about clustering in this case, only about
> rebuilding the table once I can get an exclusive lock on it. I guess
> this would be possible with the "switch to a copy" method except the new
> table is a different entity (as mentioned in another post) and it will
> not preserve the dependencies of the original table.
>
> I guess what I'm asking for is a kind of "REBUILD TABLE" which is not
> MVCC by definition but it would be useful in the mentioned queue table
> case.
>

vaccum full ?

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

pgsql-general by date:

Previous
From: Mark Harrison
Date:
Subject: Re: query that needs two nested queries, is this the best
Next
From: Robert Treat
Date:
Subject: Re: Autovacuum Logging