On Mon, May 10, 2004 at 07:49:42PM -0400, Tom Lane wrote:
>
> Hmm, I would expect that behavior for an overwrite-in-place REINDEX,
> but 7.2 only seems to use overwrite-in-place for critical system
> catalogs. What were you reindexing exactly? Were you running a
> standalone backend?
Not as far
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> Dunno if this is any help, but on a 7.2 system I saw a REINDEX which
> was interrupted leave the index at least partially working. We ended
> up with an index which seemed fine, but which didn't contain certain
> rows (so those rows were not visible wh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
|>Indicating that they should produce the same results, but that they work
|>differently. I am not sure what that implies, but maybe someone else
knows ?
| The only difference the docs are talking about is what kind of lock is
| held whi
Denis Braekhus <[EMAIL PROTECTED]> writes:
> Indicating that they should produce the same results, but that they work
> differently. I am not sure what that implies, but maybe someone else knows ?
The only difference the docs are talking about is what kind of lock is
held while the rebuild proceed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lonni Friedman wrote:
| Thanks for your reply. I thought (perhaps erroneously) that there
| wasn't any real difference between dropping an index then recreating
| it, and just reindexing an index?
I am definitely not sure, and I agree it sounds logica
Thanks for your reply. I thought (perhaps erroneously) that there
wasn't any real difference between dropping an index then recreating
it, and just reindexing an index?
On Thu, 06 May 2004 23:00:25 +0200, Denis Braekhus <[EMAIL PROTECTED]> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SH
Lonni Friedman <[EMAIL PROTECTED]> writes:
> hrmmm, i'm not sure what would constitute 'off the beaten track'.
Neither am I ... if we knew what you were doing that triggers the bug,
we'd already be halfway there :-(
regards, tom lane
---(end of bro
On Wed, 05 May 2004 13:56:41 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
> Lonni Friedman <[EMAIL PROTECTED]> writes:
> > On Wed, 05 May 2004 12:31:21 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> Once the complaint starts appearing, I'd expect it to continue until you
> >> reindex the index.
>
>
On Wed, 05 May 2004 12:31:21 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Lonni Friedman <[EMAIL PROTECTED]> writes:
> > Unfortunately, i have no clue how to replicate this. It was happening
> > fairly consistantly before i upgraded from 7.3.3 to 7.3.4 (like nearly
> > every vacuumdb run).
>
>
Lonni Friedman <[EMAIL PROTECTED]> writes:
> On Wed, 05 May 2004 12:31:21 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Once the complaint starts appearing, I'd expect it to continue until you
>> reindex the index.
> That's exactly what happens. It consistantly errors until reindexed.
> Any sugg
Its _always_ that same index. No others have had this problem.
Unfortunately, i have no clue how to replicate this. It was happening
fairly consistantly before i upgraded from 7.3.3 to 7.3.4 (like nearly
every vacuumdb run).
Then nothing for a month after going to 7.3.4, and now its happening
e
Lonni Friedman <[EMAIL PROTECTED]> writes:
> Unfortunately, i have no clue how to replicate this. It was happening
> fairly consistantly before i upgraded from 7.3.3 to 7.3.4 (like nearly
> every vacuumdb run).
> Then nothing for a month after going to 7.3.4, and now its happening
> every vacuumd
Lonni Friedman <[EMAIL PROTECTED]> writes:
> All of a sudden last month (after about 3 years) I started getting
> this warning when vacuumdb was run:
> INFO: Index pg_largeobject_loid_pn_index: Pages 903; Tuples 323847:
> Deleted 0.CPU 0.04s/0.07u sec elapsed 0.10 sec.
> WARNING: Index pg_la
13 matches
Mail list logo
