Re: tableam vs. TOAST

Ashutosh Sharma <ashu.coek88@gmail.com>

From: Ashutosh Sharma <ashu.coek88@gmail.com>
To: Craig Ringer <craig@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Prabhat Sahu <prabhat.sahu@enterprisedb.com>, Andres Freund <andres@anarazel.de>, Alvaro Herrera <alvherre@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-11-11T07:30:00Z
Lists: pgsql-hackers
Hi Craig,

Please find my response inline below.

On Sun, Nov 10, 2019 at 2:39 PM Craig Ringer <craig@2ndquadrant.com> wrote:
>
> On Thu, 7 Nov 2019 at 22:45, Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
>>
>
> In fact, I suspect this is PostgreSQL successfully protecting itself from an unsafe situation.
>
> Does the host have thin-provisioned storage? lvmthin, thin-provisioned SAN, etc?
>

No, It doesn't. Infact the machine on which the issue was reproduced
once/twice doesn't have any LVMs. The other machine on which the issue
never got reproduced have some LVMs but they are thick-provisioned not
thin-provisioned.

> Is the DB on NFS?
>

No.

--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com



Commits

  1. tableam: New callback relation_fetch_toast_slice.

  2. tableam: Allow choice of toast AM.

  3. Move heap-specific detoasting logic into a separate function.

  4. Code cleanup for toast_fetch_datum and toast_fetch_datum_slice.

  5. Rename some toasting functions based on whether they are heap-specific.

  6. Create an API for inserting and deleting rows in TOAST tables.

  7. Split tuptoaster.c into three separate files.

  8. tableam: Move heap-specific logic from needs_toast_table below tableam.