ck the non-btree
indexes during analyze (if that is possible and not too expensive).
-Original Message-
From: Neil Conway [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 14, 2004 4:39 PM
To: Scott Marlowe
Cc: Dann Corbit; pgsql-general
Subject: Re: [GENERAL] Corrupt RTREE index
On Tue, 200
sql-general
> Subject: Re: [GENERAL] Corrupt RTREE index
>
> On Tue, 2004-12-14 at 14:12 -0600, Scott Marlowe wrote:
> > IS this same issue true for hash or GiST indexes?
>
> Yes, it is: currently, only btree indexes are WAL safe.
>
> (I spent some time recently looki
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Greg Stark
Sent: Tuesday, December 14, 2004 8:49 PM
To: [EMAIL PROTECTED]
Subject: Re: [GENERAL] Corrupt RTREE index
Scott Marlowe <[EMAIL PROTECTED]> writes:
> IS this same issue true for has
Scott Marlowe <[EMAIL PROTECTED]> writes:
> IS this same issue true for hash or GiST indexes?
I think that's true, afaik rtree, GiST, and hash are all not WAL-logged.
> On Tue, 2004-12-14 at 13:49, Dann Corbit wrote:
> > I suggest a warning (if there is not already one generated) on create
> >
: Tuesday, December 14, 2004 4:39 PM
To: Scott Marlowe
Cc: Dann Corbit; pgsql-general
Subject: Re: [GENERAL] Corrupt RTREE index
On Tue, 2004-12-14 at 14:12 -0600, Scott Marlowe wrote:
> IS this same issue true for hash or GiST indexes?
Yes, it is: currently, only btree indexes are WAL safe.
On Tue, 2004-12-14 at 14:12 -0600, Scott Marlowe wrote:
> IS this same issue true for hash or GiST indexes?
Yes, it is: currently, only btree indexes are WAL safe.
(I spent some time recently looking into adding page-level concurrency
and WAL to GiST, but I haven't had a chance to finish that wor
age-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
> Sent: Monday, December 13, 2004 4:14 PM
> To: Greg Stark
> Cc: [EMAIL PROTECTED]
> Subject: Re: [GENERAL] Corrupt RTREE index
>
> Greg Stark <[EMAIL PROTECTED]> writes:
> > So yo
Stark
Cc: [EMAIL PROTECTED]
Subject: Re: [GENERAL] Corrupt RTREE index
Greg Stark <[EMAIL PROTECTED]> writes:
> So you don't think this case is worth doing forensics on?
If the problem goes away after REINDEX then I'll write it off as missing
WAL support. rtree is not high e
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > So you don't think this case is worth doing forensics on?
>
> If the problem goes away after REINDEX then I'll write it off as missing
> WAL support. rtree is not high enough on my list of priorities to
> justify m
Greg Stark <[EMAIL PROTECTED]> writes:
> I have what appears to be a corrupt RTREE index.
I wonder if it's actually corrupt, or if it's just that the index
semantics don't truly match the operator. If the latter, REINDEXing
won't fix it.
As for the first theory, have you had any database crashes
Greg Stark <[EMAIL PROTECTED]> writes:
> So you don't think this case is worth doing forensics on?
If the problem goes away after REINDEX then I'll write it off as missing
WAL support. rtree is not high enough on my list of priorities to
justify more effort :-(
regards, t
Tom Lane <[EMAIL PROTECTED]> writes:
> I wonder if it's actually corrupt, or if it's just that the index
> semantics don't truly match the operator. If the latter, REINDEXing
> won't fix it.
I think the index always worked properly in the past. But of course it would
be hard to tell if that was
12 matches
Mail list logo
