Re: BUG #10823: Better REINDEX syntax.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: dmigowski(at)ikoffice(dot)de, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #10823: Better REINDEX syntax.
Date: 2014-07-30 17:46:59
Message-ID: 1840.1406742419@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Wed, Jul 30, 2014 at 01:29:31PM -0400, Tom Lane wrote:
>> I don't find it all that odd. We should not be encouraging routine
>> database-wide reindexes.

> Uh, do we encourage database-wide VACUUM FULL or CLUSTER, as we use them
> there with no parameter. Is there a reason REINDEX should be harder,
> and require a dummy argument to run?

I believe that REINDEX on system catalogs carries a risk of deadlock
failures against other processes --- there was a recent example of that
in the mailing lists. VACUUM FULL has such risks too, but that's been
pretty well deprecated for many years. (I think CLUSTER is probably
relatively safe on this score because it's not going to think any system
catalogs are clustered.)

If there were a variant of REINDEX that only hit user tables, I'd be fine
with making that easy to invoke.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Vik Fearing 2014-07-30 17:48:39 Re: BUG #10823: Better REINDEX syntax.
Previous Message Bruce Momjian 2014-07-30 17:35:55 Re: BUG #10823: Better REINDEX syntax.

Browse pgsql-hackers by date

  From Date Subject
Next Message Vik Fearing 2014-07-30 17:48:39 Re: BUG #10823: Better REINDEX syntax.
Previous Message Robert Haas 2014-07-30 17:36:01 Re: Making joins involving ctid work for the benefit of UPSERT