Re: Bugs in TOAST handling, OID assignment and redo recovery

From: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bugs in TOAST handling, OID assignment and redo recovery
Date: 2018-04-11 18:43:18
Message-ID: CABOikdNoU8=5RjckqwnBFhjrgF4DU0SWw7sPry5Qfo4q7N0-4Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 11, 2018 at 8:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> writes:
> > Or may be we simply err on the side of caution and scan the toast table
> > with SnapshotAny while looking for a duplicate? That might prevent us
> from
> > reusing an OID for a known-dead tuple, but should save us a second index
> > scan and still work.
>
> +1. We really don't want to expend two indexscans on this.
>
>
Ok. I propose attached patches, more polished this time. I also
changed toastrel_valueid_exists() to use SnapshotAny, but I don't have any
proofs to claim that's a needed change. But it seems harmless and given the
number of toast related, hard to chase bugs we have seen over the years,
may it's worth making it full proof too.

Thanks,
Pavan

--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
0002-Do-more-extensive-search-while-looking-for-duplicate.patch application/octet-stream 6.1 KB
0001-Do-not-overwrite-the-nextOid-counter-while-replaying.patch application/octet-stream 3.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2018-04-11 18:53:05 Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.
Previous Message Chapman Flack 2018-04-11 18:38:46 Re: lazy detoasting