On Fri, Apr 22, 2011 at 7:07 PM, <tv@xxxxxxxx> wrote: >> On Fri, Apr 22, 2011 at 12:06 PM, Phoenix Kiula <phoenix.kiula@xxxxxxxxx> >> wrote: >>> On Fri, Apr 22, 2011 at 12:51 AM, Tomas Vondra <tv@xxxxxxxx> wrote: >>>> Dne 21.4.2011 07:16, Phoenix Kiula napsal(a): >>>>> Tomas, >>>>> >>>>> I did a crash log with the strace for PID of the index command as you >>>>> suggested. >>>>> >>>>> Here's the output: >>>>> http://www.heypasteit.com/clip/WNR >>>>> >>>>> Also including below, but because this will wrap etc, you can look at >>>>> the link above. >>>>> >>>>> Thanks for any ideas or pointers! >>>>> >>>>> >>>>> >>>>> Process 15900 attached - interrupt to quit >>>> >>>> Nope, that's the "psql" process - you need to attach to the backend >>>> process that's created to handle the connection. Whenever you create a >>>> connection (from a psql), a new backend process is forked to handle >>>> that >>>> single connection - this is the process you need to strace. >>>> >>>> You can either see that in 'ps ax' (the PID is usually +1 with respect >>>> to the psql process), or you can do this >>>> >>>> SELECT pg_backend_pid(); >>>> >>>> as that will give you PID of the backend for the current connection. >>> >>> >>> >>> >>> >>> Thanks. Did that. >>> >>> The crash.log is a large-ish file, about 24KB. Here's the last 10 >>> lines though. Does this help? >>> >>> >>> >>> ~ > tail -10 /root/crash.log >>> read(58, "`\1\0\0\230\337\0\343\1\0\0\0P\0T\r\0 \3 >>> \374\236\2\2T\215\312\1\354\235\32\2"..., 8192) = 8192 >>> write(97, "213.156.60\0\0 \0\0\0\37\0\364P\3\0\34@\22\0\0\000210."..., >>> 8192) = 8192 >>> read(58, "`\1\0\0\274\362\0\343\1\0\0\0T\0\210\r\0 \3 >>> 0\217\352\1\240\236\272\0024\235\322\2"..., 8192) = 8192 >>> read(58, "[\1\0\0\354)c*\1\0\0\0T\0\214\r\0 \3 >>> \254\236\242\2\340\220\342\2\\\235\232\2"..., 8192) = 8192 >>> read(58, "\\\1\0\0\200\245\207\32\1\0\0\0\\\0\340\r\0 \3 >>> \237\272\1\304\235\262\2\340\215\322\1"..., 8192) = 8192 >>> read(58, "\350\0\0\0\274\311x\323\1\0\0\0\\\0000\r\0 \3 >>> \200\236\372\2(\235\252\2\34\234\22\2"..., 8192) = 8192 >>> read(58, ";\1\0\0|#\265\30\1\0\0\0`\0h\r\0 \3 >>> \324\236R\2\314\235\n\2h\215\362\1"..., 8192) = 8192 >>> read(58, "c\1\0\0000\24%u\1\0\0\0\230\0\210\r\0 \3 >>> \240\226\32\16\260\235\252\1p\222Z\10"..., 8192) = 8192 >>> --- SIGSEGV (Segmentation fault) @ 0 (0) --- >>> Process 17161 detached >>> >>> >>> >>> The full crash.log file is here if needed: >>> https://www.yousendit.com/download/ VnBxcmxjNDJlM1JjR0E9PQ >>> >>> Btw, this happens when I try to create an index on one of the columns >>> in my table. >>> >>> Just before this, I had created another index on modify_date (a >>> timestamp column) and it went fine. >>> >>> Does that mean anything? >>> >>> Thanks >>> >> >> >> >> Probably a dumb and ignorant question, but should I be reseting the xlog? >> http://postgresql.1045698.n5.nabble.com/SIGSEGV-when-trying-to-start-in-single-user-mode-td1924418.html > > Nope, that's a different problem I guess - you don't have problems with > starting up a database (when the logs are replayed), so this would not > help (and it might cause other issues). > > Anyway I haven't found anything useful in the strace output - it seems it > works fine, reads about 500MB (each of the 'read' calls corresponds to 8kB > of data) of data and then suddenly ends. A bit strange is the last line is > not complete ... > > Anyway, this is where my current knowledge of how processes in PostgreSQL > ends. If I was sitting at the terminal, I'd probably continue by try and > error to find out more details about the segfault, but that's not very > applicable over e-mail. > > So let's hope some of the pg gurus who read this list will enlighten us > with a bit more knowledge. > > regards > Tomas > > In the pg_dumpall backup process, I get this error. Does this help? pg_dump: SQL command failed pg_dump: Error message from server: ERROR: invalid memory alloc request size 4294967293 pg_dump: The command was: COPY public.links (id, link_id, alias, aliasentered, url, user_known, user_id, url_encrypted, title, private, private_key, status, create_date, modify_date, disable_in_statistics, user_running_id, url_host_long) TO stdout; pg_dumpall: pg_dump failed on database "snipurl", exiting Thanks! -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
