Re: pgsql-server/src/backend catalog/index.c comma ...

From: "Hiroshi Inoue" <inoue(at)tpf(dot)co(dot)jp>
To: "'Marc G(dot) Fournier'" <scrappy(at)postgresql(dot)org>
Cc: <pgsql-committers(at)postgresql(dot)org>
Subject: Re: pgsql-server/src/backend catalog/index.c comma ...
Date: 2003-09-21 11:04:43
Message-ID: 001701c38030$2953f720$3d283ddb@PbgX
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers pgsql-patches

> -----Original Message-----
> From: Marc G. Fournier [mailto:scrappy(at)postgresql(dot)org]
> Sent: Sunday, September 21, 2003 6:45 AM
> To: Hiroshi Inoue
> Cc: 'Tom Lane'; pgsql-committers(at)postgresql(dot)org
> Subject: Re: [COMMITTERS] pgsql-server/src/backend
> catalog/index.c comma ...
>
> On Sun, 21 Sep 2003, Hiroshi Inoue wrote:
>
> > > "Hiroshi Inoue" <inoue(at)tpf(dot)co(dot)jp> writes:
> > > > Why could you determine it ? Is PostgreSQL your system ?
> > >
> > > Well, if you prefer, we can have a discussion and vote about
> > > it on pghackers.
> >
> > Oh discussion *first* is good but You committed *first*.
> > So isn't it reasonable to revert your change *first* ?
> >
> > This is the second time you disable the on-line reindex
> > functionality for system tables. Why must I explain the
> > same thing many times ?
>
> Actually, as a comment here, since I *think* I understand where Tom is
> coming from ... and since I've either missed it, or it hasn't been
> answered yet ... why was the original patch incomplete in
> only addressing
> 1 of 3 REINDEX conditions? Is there a reason why that one condition
> is/was safe to do it with, but not the other 2?

Sorry to trouble you.

In the first place, REINDEX is neither an SQL standard command nor
a preferable one.

When I introduced REINDEX command before 7.0, it was not
transaction-safe and only allowed to call under standalone mode
essentially.

Before 7.1, the introduction of pg_class.relfilenode gave us a possibilty
to make REINDEX command transaction-safe and I tried to make
REINDEX available under postmaster and the result was
1.All user indexes/tables could be REINDEXed under postmaster
2.System tables except shared or nailed ones could be REINDEXed
under postmaster.

Note that we couldn't reindex all system tables under postmaster.
It's the main reason why I didn't implement REINDEX DATABASE
under postmaster. As for REINDEX, I have

Tue Nov 20 02:46:13 2001 UTC (22 months ago) Tom committed
the following change which disables the functionality to reindex
system tables under postmaster.
Some minor tweaks of REINDEX processing: grab exclusive
lock a little earlier, make error checks more uniform.

The above change was the first time he disables the functionality.
I noticed the change, complained to him and
Thu Feb 7 00:27:30 2002 UTC (19 months, 1 week ago) I
Removed a check for REINDEX TABLE.

And this is the second time he disables the functionality without
any notification to me. Honestly I don't understand why I have to
explain this kind of thing only so as to revert the change.

regards,
Hiroshi Inoue

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2003-09-21 17:42:22 pgsql-server/src/interfaces/ecpg/pgtypeslib co ...
Previous Message Christopher Kings-Lynne 2003-09-21 03:51:47 Re: pgsql-server/ rc/backend/catalog/sql_features. ...

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2003-09-21 15:37:59 Error message cleanup
Previous Message Manfred Spraul 2003-09-21 10:49:45 Re: Align large shared memory allocations

Browse pgsql-patches by date

  From Date Subject
Next Message Mike Mascari 2003-09-21 11:05:55 Re: contrib mode - pgenv
Previous Message Manfred Spraul 2003-09-21 10:49:45 Re: Align large shared memory allocations