Re: BUG #3595: Segmentation fault with a simple select query

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Heikki Linnakangas kirjoitti:
> Jukka Holappa wrote:
>> I can't easily reproduce this problem but it happens in every few hours in
>> my use.
>
> Can you get a core dump and/or a stack trace out of it? I noted that
> you're running Gentoo, so recompiling with --enable-debug, if it's not
> compiled with it already, shouldn't be a problem :). --enable-cassert
> could be helpful as well, though that does have an impact on performace.
>
> Let me know if you need help compiling or getting a core dump or stack
> trace with gdb.
>
>> I'm a bit loss about what could cause this. Is there a way to check the
>> current database for possible corruption? Regular queries seem to work ok.
>
> Not really. If the query that crashed works when ran after restart, it's
> not likely that corruption caused the crash. You could take a backup
> with pg_dump; that at least scans through all data, so if something is
> corrupted in a table it will complain.
>

You're right. Dumping out works just fine and it doesn't complain
anything. With my problem case I didn't actually have the data there
that I was querying for.. so the problem could have been with the index
used.

I have been trying to repeat this problem with all the debugging
information on.. and with gdb ready.. but I have been unable to
reproduce the problem.

Because of my mistakes with debugging the postmaster process and perhaps
not always shutting it down properly, I might have caused some problems
myself.. so the results may not be so reliable any more. I'll restore
from my database dump and let it run again without fiddling around too much.

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

I'll keep trying to produce a clean crash report if at all possible.

- - Jukka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG3Y+mYYWM2XTSwX0RAztjAJ9idxeXULMNUycfpFjN3+oPyJ9VqgCcCZvn
zL1ARtPynJz6NGUuzmQJyyE=
=r/ey
-----END PGP SIGNATURE-----