Re: tableam vs. TOAST

From: Prabhat Sahu <prabhat(dot)sahu(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: tableam vs. TOAST
Date: 2019-10-31 04:56:27
Message-ID: CANEvxPo4X4=dtEKpW0cy0HoQskPY6KmmXq6-g=zS0ADcQHLmbQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 30, 2019 at 9:46 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Wed, Oct 30, 2019 at 3:49 AM Prabhat Sahu <
> prabhat(dot)sahu(at)enterprisedb(dot)com> wrote:
>
>> While testing the Toast patch(PG+v7 patch) I found below server crash.
>> System configuration:
>> VCPUs: 4, RAM: 8GB, Storage: 320GB
>>
>> This issue is not frequently reproducible, we need to repeat the same
>> testcase multiple times.
>>
>
> I wonder if this is an independent bug, because the backtrace doesn't look
> like it's related to the stuff this is changing. Your report doesn't
> specify whether you can also reproduce the problem without the patch, which
> is something that you should always check before reporting a bug in a
> particular patch.
>

Hi Robert,

My sincere apologize that I have not mentioned the issue in more detail.
I have ran the same case against both PG HEAD and HEAD+Patch multiple
times(7, 10, 20nos), and
as I found this issue was not failing in HEAD and same case is reproducible
in HEAD+Patch (again I was not sure about the backtrace whether its related
to patch or not).

> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

--

With Regards,

Prabhat Kumar Sahu
Skype ID: prabhat.sahu1984
EnterpriseDB Software India Pvt. Ltd.

The Postgres Database Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2019-10-31 06:03:33 Re: [HACKERS] Block level parallel vacuum
Previous Message Tom Lane 2019-10-31 04:56:16 Re: Creating foreign key on partitioned table is too slow