Re: Computer VARSIZE_ANY(PTR) during debugging
От | Amit Langote |
---|---|
Тема | Re: Computer VARSIZE_ANY(PTR) during debugging |
Дата | |
Msg-id | CA+HiwqHtJ3mfXbFK68LQ=3j0tyVjEXJoZ1ztw9eVdyP3iK7E=g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Computer VARSIZE_ANY(PTR) during debugging (Greg Stark <stark@mit.edu>) |
Список | pgsql-hackers |
On Wed, Jul 31, 2013 at 2:33 AM, Greg Stark <stark@mit.edu> wrote: > I think there's some magic in gdb for this but I'm not sure how to > make it happen. If you figure it out I would think it would be > generally useful and we should find a way to put it in the source tree > so it works for everyone. > > You might find it useful to put breakpoints in heap_deformtuple() with > conditions that catch the tuple you're looking for. That function will > often (but not always) be the first function to see your corrupt > tuple. With the core dump using which I worked on this problem about a month back, I couldn't find heap_deformtuple() in the code path that resulted in the segfault. As I said, it was slot_deform_tuple(). Is it possible that it would be in the code path for a query like: select bpcharcol1, bpcharcol2, int4col3, bpcharcol4, octet_length(textcol5) from table where octet_length(textcol5) > 8000000; -- Amit Langote
В списке pgsql-hackers по дате отправления: