From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Computer VARSIZE_ANY(PTR) during debugging |
Date: | 2013-07-31 00:57:50 |
Message-ID: | CA+HiwqHtJ3mfXbFK68LQ=3j0tyVjEXJoZ1ztw9eVdyP3iK7E=g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 31, 2013 at 2:33 AM, Greg Stark <stark(at)mit(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-07-31 01:39:14 | Re: [COMMITTERS] pgsql: Add support for REFRESH MATERIALIZED VIEW CONCURRENTLY. |
Previous Message | David Fetter | 2013-07-31 00:33:18 | Re: pass-through queries to foreign servers |