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 as
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 when
-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
-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
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 proceeds.
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: SHA1
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
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 vacuumdb run
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
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 suggestions?
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).
Then
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.
That's exactly
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
13 matches
Mail list logo
