-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Heikki Linnakangas kirjoitti:
> Jukka Holappa wrote:
>> Currently it has some problem with another index for sure as it says:
>> 'ERROR: could not find left sibling in "next_indexing_key"' and when
>> trying to recreate the url table index that was used in the problematic
>> query I reported about, I had some errors like:
>>
>> NOTICE: ALTER TABLE / ADD UNIQUE will create implicit index
>> "unique_urls" for table "urls"
>> ERROR: xlog flush request 3F/1868BB20 is not satisfied --- flushed only
>> to 3F/833AF28
>> CONTEXT: writing block 4018 of relation 1663/46508/79461
>
> The likely cause for that is that the LSN on a data page is corrupted.
> It tried to flush the WAL up to location 3F/1868BB20, but there wasn't
> that much WAL generated.
>
Like I said above quoted parts, the likely cause for this problem was my
own mistake by closing down postgresql the wrong way.
> It starts to sound more and more like a hardware problem to me. You
> mentioned that you have no other software crashes, but I wonder if
> you're running anything else on the server that stresses it in any
> significant way. I'd suggest checking/replacing the RAM for starters,
> that's the most common component to fail, and would cause random
> corruption like that. Or if you have spare hardware, switch to another
> server and see if the problem goes reappears.
>
Of course it can be a hardware problem, but I still don't think so.
However, I can't replicate the original problem at this time and
original broken files (with the original problem from the time before my
feeble debugging attempts) are gone at this point anyway.
I think you can close this bug report down as a bogus one and I'll get
back to you if I have something solid to show later on.
- - Jukka
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG5l+zYYWM2XTSwX0RA4G0AJ4zjTEd8szpOeZJWuh05vPTg4BYiACfV8gk
HoxfbB/GDMvl7JbaHux6X+Y=
=mVVe
-END PGP SIGNATURE-
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
