On Sat, Sep 27, 2003 at 08:18:07PM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > > What about creating a separate filenode anyway and renaming the files
> > > afterwards? It would not be an atomic operation anyway, but it would be
> > > better than the current setup IMHO.
> >
> > I think it w
Tom Lane wrote:
> > What about creating a separate filenode anyway and renaming the files
> > afterwards? It would not be an atomic operation anyway, but it would be
> > better than the current setup IMHO.
>
> I think it would be difficult to persuade the buffer manager and storage
> manager to w
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Sat, Sep 27, 2003 at 06:37:22PM -0400, Tom Lane wrote:
>> I don't see any way to avoid that, though, since we cannot change the
>> relfilenode value for a shared index.
> What about creating a separate filenode anyway and renaming the files
> afterwa
On Sat, Sep 27, 2003 at 06:37:22PM -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom, would you summarize what REINDEX currently _doesn't_ do?
>
> As of CVS tip I think the only deficiency is that indexes on the shared
> catalogs (pg_database, pg_shadow, pg_group) have to
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom, would you summarize what REINDEX currently _doesn't_ do?
>
> As of CVS tip I think the only deficiency is that indexes on the shared
> catalogs (pg_database, pg_shadow, pg_group) have to be reindexed in
> place, rather than being
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, would you summarize what REINDEX currently _doesn't_ do?
As of CVS tip I think the only deficiency is that indexes on the shared
catalogs (pg_database, pg_shadow, pg_group) have to be reindexed in
place, rather than being rebuilt with a new relfilen
Tom, would you summarize what REINDEX currently _doesn't_ do?
---
Tom Lane wrote:
> I've been looking at the issues involved in reindexing system tables,
> and I now have what I think is a fairly defensible set of proposals.
Hiroshi Inoue wrote:
Gaetano Mendola [mailto:[EMAIL PROTECTED] wrote:
Hiroshi Inoue wrote:
instead. Because it was impossible to make REINDEX transaction-safe
then, such flag was needed to suppress inconsistency as less
as possible.
This mean that the actual REINDEX is not transaction-safe ?
No
> -Original Message-
> From: Gaetano Mendola [mailto:[EMAIL PROTECTED]
>
> Hiroshi Inoue wrote:
> > instead. Because it was impossible to make REINDEX transaction-safe
> > then, such flag was needed to suppress inconsistency as less
> > as possible.
>
> This mean that the actual REINDEX
Hiroshi Inoue wrote:
> instead. Because it was impossible to make REINDEX transaction-safe
> then, such flag was needed to suppress inconsistency as less
> as possible.
This mean that the actual REINDEX is not transaction-safe ?
Regards
Gaetano Mendola
---(end of broadc
I've just put back your previous change, sorry.
As I already mentioned many times it must be the first thing.
Though I don't remenber my code completely yet, I would
reply to some points.
Unfortunately REINDEX wasn't a eagerly wanted command when
I implemented it. Though I want
Tom Lane wrote:
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > I require you to explain me why you committed the change
> > with no discussion and little investigation.
>
> If you want an apology for not having discussed it in advance, I'll
> gladly offer one. It was po
Kurt Roeckx wrote:
>
> On Mon, Sep 22, 2003 at 04:56:35AM +0900, Hiroshi Inoue wrote:
> > First it should have been discussed before your commitment or at least
> > it should be discussed after reversing your change.
> >
> > I require you to explain me why you committed the chang
On Mon, Sep 22, 2003 at 04:56:35AM +0900, Hiroshi Inoue wrote:
> First it should have been discussed before your commitment or at least
> it should be discussed after reversing your change.
>
> I require you to explain me why you committed the change
> with no discussion and little investigation.
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> I require you to explain me why you committed the change
> with no discussion and little investigation.
If you want an apology for not having discussed it in advance, I'll
gladly offer one. It was poorly done.
I do, however, think that the reindexing
First it should have been discussed before your commitment or at least
it should be discussed after reversing your change.
I require you to explain me why you committed the change
with no discussion and little investigation.
I also noticed that your change for catalog/index.c
Revision 1.200
I've been looking at the issues involved in reindexing system tables,
and I now have what I think is a fairly defensible set of proposals.
We should whenever possible use the same reindexing technique used by
CLUSTER: assign a new relfilenode number, build the new index in that
file, and apply an
17 matches
Mail list logo
