Horton

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

Pavan Deolasee <pavan.deolasee@gmail.com>

View thread View on postgr.es
From: Pavan Deolasee <pavan.deolasee@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-04-11T11:51:28Z
Lists: pgsql-hackers 
On Tue, Apr 10, 2018 at 7:24 PM, Pavan Deolasee <pavan.deolasee@gmail.com>
wrote:

> Hi Heikki,
>
> On Tue, Apr 10, 2018 at 7:07 PM, Heikki Linnakangas <hlinnaka@iki.fi>
> wrote:
>
>>
>>>
>> It would seem more straightforward to add a snapshot parameter to
>> GetNewOidWithIndex(), so that the this one caller could pass SnapshotToast,
>> while others pass SnapshotDirty. With your patch, you check the index
>> twice: first with SnapshotDirty, in GetNewOidWithIndex(), and then with
>> SnapshotToast, in the caller.
>>
>
> Hmm. I actually wrote my first patch exactly like that. I am trying to
> remember why I discarded that approach. Was that to do with the fact that  SnapshotToast
> can't see all toast tuples either? Yeah, I think so. For example, it won't
> see tuples with uncommitted-xmin, leading to different issues. Now it's
> unlikely that we will have a OID conflict where the old tuple has
> uncommitted-xmin, but not sure if we can completely rule that out.
>

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.

Thanks,
Pavan

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

Commits

  1. Ignore nextOid when replaying an ONLINE checkpoint.

  2. Do not select new object OIDs that match recently-dead entries.