Re: CLUSTER and MVCC

Поиск
Список
Период
Сортировка
От Csaba Nagy
Тема Re: CLUSTER and MVCC
Дата
Msg-id 1173444657.9058.73.camel@coppola.muc.ecircle.de
обсуждение исходный текст
Ответ на Re: CLUSTER and MVCC  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-hackers
On Fri, 2007-03-09 at 13:42, Gregory Stark wrote:
> "Csaba Nagy" <nagy@ecircle-ag.com> writes:
> 
> > Wouldn't be possible to do it like Simon (IIRC) suggested, and add a
> > parameter to enable/disable the current behavior, and use the MVCC
> > behavior as default ?
> 
> Doing it in CLUSTER would be weird. However perhaps it would be useful to have
> some sort of stand-alone tool that just bumped all the xmin/xmax's. It would
> have to be super-user-only and carry big warning labels saying it breaks MVCC.

Well, the current behavior of CLUSTER is just perfect for what I'm using
it. If anything else would do the job, I would be happy to use it
instead...

> But it would be useful any time you have a table that you want to exempt a
> particular table from serializable snapshots. Basically a per-table way to
> force a read-committed snapshot on. Though, actually it's not quite a
> read-committed snapshot is it? Anyone using an old serializable snapshot will
> see what, no tuples at all?

I'm afraid what I need has nothing to do with serializable snapshots...
I still want the table to be completely transactional except if somebody
can get an exclusive lock on it, it can be compacted regardless of other
running transactions. I'm not sure how to express this in other way...
it means something like: no transaction cares about the content of the
table until it gets some kind of lock on it. In other words the table's
state is not connected with the state of other tables until I actually
do something on it...

Cheers,
Csaba.




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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: RFC: changing autovacuum_naptime semantics
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: CLUSTER and MVCC