-----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
