| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Csaba Nagy" <nagy(at)ecircle-ag(dot)com> |
| Cc: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "postgres hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: CLUSTER and MVCC |
| Date: | 2007-03-09 12:42:58 |
| Message-ID: | 87fy8e4mgd.fsf@stark.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Csaba Nagy" <nagy(at)ecircle-ag(dot)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.
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?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2007-03-09 12:48:59 | Re: RFC: changing autovacuum_naptime semantics |
| Previous Message | Luke Lonergan | 2007-03-09 12:40:06 | Re: Auto creation of Partitions |