Re: [WIP] [B-Tree] Retail IndexTuple deletion - Mailing list pgsql-hackers

From Kuntal Ghosh
Subject Re: [WIP] [B-Tree] Retail IndexTuple deletion
Date
Msg-id CAGz5QC+u-PF__09DqzAVnuR25gjEpOvQu1DdePD2_FD=YMmTWw@mail.gmail.com
Whole thread Raw
In response to Re: [WIP] [B-Tree] Retail IndexTuple deletion  ("Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru>)
Responses Re: [WIP] [B-Tree] Retail IndexTuple deletion
List pgsql-hackers
On Wed, Jun 27, 2018 at 12:10 PM, Andrey V. Lepikhov
<a.lepikhov@postgrespro.ru> wrote:
> I prepare third version of the patches. Summary:
> 1. Mask DEAD tuples at a page during consistency checking (See comments for
> the mask_dead_tuples() function).

- ItemIdSetDead(lp);
+ if (target_index_deletion_factor > 0)
+ ItemIdMarkDead(lp);
+ else
+ ItemIdSetDead(lp);
IIUC, you want to hold the storage of DEAD tuples to form the ScanKey
which is required for the index scan in the second phase of quick
vacuum strategy. To achieve that, you've only marked the tuple as DEAD
during pruning. Hence, PageRepairFragmentation cannot claim the space
for DEAD tuples since they still have storage associated with them.
But, you've WAL-logged it as DEAD tuples having no storage. So, when
the WAL record is replayed in standby(or crash recovery), the tuples
will be marked as DEAD having no storage and their space may be
reclaimed by PageRepairFragmentation. Now, if you do byte-by-byte
comparison with wal_consistency tool, it may fail even for normal
tuple as well. Please let me know if you feel the same way.

-- 
Thanks & Regards,
Kuntal Ghosh
EnterpriseDB: http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: partition tree inspection functions
Next
From: Dilip Kumar
Date:
Subject: Re: partition tree inspection functions