Re: CLUSTER and MVCC - Mailing list pgsql-hackers

From Csaba Nagy
Subject Re: CLUSTER and MVCC
Date
Msg-id 1173444657.9058.73.camel@coppola.muc.ecircle.de
Whole thread Raw
In response to Re: CLUSTER and MVCC  (Gregory Stark <stark@enterprisedb.com>)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: RFC: changing autovacuum_naptime semantics
Next
From: Heikki Linnakangas
Date:
Subject: Re: CLUSTER and MVCC