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
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. ... |
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 |
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 |