On Wed, Jun 01, 2005 at 06:55:46PM +0100, Simon Riggs wrote:
> On Wed, 2005-06-01 at 11:55 -0400, Tom Lane wrote:
> > Simon Riggs <simon@2ndquadrant.com> writes:
> > > 4. Optionally, we set a flag on the table showing the whole table is
> > > frozen. Anybody writing to this table subsequently will spoil this flag.
> > > If the flag is set, all forms of VACUUM will return success immediately
> > > without performing a scan (since it is already in a perfect VACUUM FULL
> > > and VACUUM FREEZE state).
> >
> > This bit strikes me as dangerous and not related to the original
> > proposal. I don't care for the load-already-frozen-data part at all,
> > either. That's not just giving up WAL protection, that's an outright
> > MVCC semantics violation, in return for which we get ... not much.
> > Certainly not any speedup in the LOAD itself.
>
> I agree it *sounds* dangerous, but is it? If so, how? I will immediately
> withdraw any idea that proves dangerous.
>
> We're holding the table lock and will continue to do so until end of
> transaction. No transaction with an earlier id will ever see the data we
> load because of the lock.
Suppose you load half the tuples and the plug is pulled. After
recovery, you have half-load of tuples that are visible to everyone.
This is a no-no. Plus, what is the benefit of having the tuples in
frozen state to start with? If this is a data warehouse application,
I'd expect the table to be dropped or truncated rather before the
billion-transactions barrier comes to pass.
--
Alvaro Herrera (<alvherre[a]surnet.cl>)
"I dream about dreams about dreams", sang the nightingale
under the pale moon (Sandman)