Re: [HACKERS] Index recreation in vacuum - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] Index recreation in vacuum
Date
Msg-id 200001190308.WAA13965@candle.pha.pa.us
Whole thread Raw
In response to RE: [HACKERS] Index recreation in vacuum  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
List pgsql-hackers
> I heard from someone that old vacuum had been like so.
> Probably 2x disk space for big tables was a big disadvantage.

That's interesting.

> 
> In addition,rename(),unlink(),mv aren't preferable for transaction
> control as far as I see. We couldn't avoid inconsistency using
> those OS functions.

I disagree.  Vacuum can't be rolled back anyway in the sense you can
bring back expire tuples, though I have no idea why you would want to.

You have an exclusive lock on the table.  Putting new heap/indexes in
place that match and have no expired tuples seems like it can not fail
in any situation.

Of course, the buffers of the old table have to be marked as invalid,
but with an exclusive lock, that is not a problem.  I am sure we do that
anyway�in vacuum.

> We have to wait the change of relation file naming if copying
> vacuum is needed.
> Under the spec we need not rename(),mv etc.

Sorry, I don't agree, yet...

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: "Hiroshi Inoue"
Date:
Subject: RE: [HACKERS] Index recreation in vacuum
Next
From: Thomas Lockhart
Date:
Subject: Re: Date/time types (Re: [HACKERS] Re: [COMMITTERS] pgsql/src/include/catalog(pg_type.h))