Re: [WIP] [B-Tree] Retail IndexTuple deletion

On 29.06.2018 10:00, Kuntal Ghosh wrote:
> On Wed, Jun 27, 2018 at 12:10 PM, Andrey V. Lepikhov
> <a(dot)lepikhov(at)postgrespro(dot)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 for your analysis.
In this development version of the patch I expect the same prune()
strategy on a master and standby (i.e. target_index_deletion_factor is
equal for both).
In this case storage of a DEAD tuple holds during replay or recovery in
the same way.
On some future step of development I plan to use more flexible prune()
strategy. This will require to append a 'isDeadStorageHold' field to the
WAL record.

--
Regards,
Andrey Lepikhov
Postgres Professional:
https://postgrespro.com
The Russian Postgres Company