Re: Alternative for vacuuming queue-like tables

Поиск
Список
Период
Сортировка
От Robert Treat
Тема Re: Alternative for vacuuming queue-like tables
Дата
Msg-id 200604281352.14380.xzilla@users.sourceforge.net
обсуждение исходный текст
Ответ на Re: Alternative for vacuuming queue-like tables  (Csaba Nagy <nagy@ecircle-ag.com>)
Ответы Re: Alternative for vacuuming queue-like tables  (Csaba Nagy <nagy@ecircle-ag.com>)
Список 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 по дате отправления:

Предыдущее
От: Mark Harrison
Дата:
Сообщение: Re: query that needs two nested queries, is this the best
Следующее
От: Robert Treat
Дата:
Сообщение: Re: Autovacuum Logging