Re: Alternative for vacuuming queue-like tables

Поиск
Список
Период
Сортировка
От Csaba Nagy
Тема Re: Alternative for vacuuming queue-like tables
Дата
Msg-id 1146241231.14093.107.camel@coppola.muc.ecircle.de
обсуждение исходный текст
Ответ на Re: Alternative for vacuuming queue-like tables  (Chris Browne <cbbrowne@acm.org>)
Ответы Re: Alternative for vacuuming queue-like tables  (Robert Treat <xzilla@users.sourceforge.net>)
Re: Alternative for vacuuming queue-like tables  ("Florian G. Pflug" <fgp@phlo.org>)
Список pgsql-general
> 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.

Cheers,
Csaba.



В списке pgsql-general по дате отправления:

Предыдущее
От: Chris Browne
Дата:
Сообщение: Re: Alternative for vacuuming queue-like tables
Следующее
От: "Andrus"
Дата:
Сообщение: Re: How to define + operator for strings