Re: Help - corruption issue? - Mailing list pgsql-general

From Phoenix Kiula
Subject Re: Help - corruption issue?
Date
Msg-id BANLkTi=dsUebgnOegzTO2RuzXzrvpyB+Hw@mail.gmail.com
Whole thread Raw
In response to Re: Help - corruption issue?  (tv@fuzzy.cz)
Responses Re: Help - corruption issue?
List pgsql-general
On Fri, Apr 22, 2011 at 7:07 PM,  <tv@fuzzy.cz> wrote:
>> On Fri, Apr 22, 2011 at 12:06 PM, Phoenix Kiula <phoenix.kiula@gmail.com>
>> wrote:
>>> On Fri, Apr 22, 2011 at 12:51 AM, Tomas Vondra <tv@fuzzy.cz> 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!

pgsql-general by date:

Previous
From: tv@fuzzy.cz
Date:
Subject: Re: Help - corruption issue?
Next
From: tv@fuzzy.cz
Date:
Subject: Re: Help - corruption issue?