Kelly Burkhart <kelly.burkhart@xxxxxxxxx> writes: > The crash left a core file, does the stack trace indicate anything crucial? > (gdb) where > #0 0x000000000068d884 in SearchCatCacheList () > #1 0x0000000100000000 in ?? () > #2 0x0000000000bbcbe0 in ?? () > #3 0x00007f3b3a86a580 in ?? () > #4 0x72ddbea20068dae0 in ?? () > #5 0x00007fff78faa720 in ?? () > #6 0x0000000000000000 in ?? () > Current language: auto > The current source language is "auto; currently asm". That's pretty much useless unless you can install debug symbols and try again. I will say though that this is probably a new bug --- I don't recall seeing anything crashing in SearchCatCacheList recently. > Can anyone provide some guidance on how I can go about discovering the > cause? Please try to create a reproducible test case. One thing you can get to start from is the query that was being executed --- try this in gdb: p debug_query_string If that just gives you a number and not the text of a SQL query, try p (char *) debug_query_string regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
