Re: 64-bit XIDs in deleted nbtree pages

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: 64-bit XIDs in deleted nbtree pages
Date: 2021-02-22 12:20:23
Message-ID: CAD21AoAJur1ZbZzTo7qier0mrOjSMgNf=fVyPE+H4gk1CxsjOw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 19, 2021 at 3:18 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Fri, Feb 19, 2021 at 3:12 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> >
> > On Thu, Feb 18, 2021 at 3:13 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > > Agreed. Thanks for your explanation.
> >
> > Attached is v5, which has some of the changes I talked about. Changes
> > from v4 include:
> >
> > * Now only updates metapage during btvacuumcleanup() in the first
> > patch, which is enough to fix the existing
> > IndexVacuumInfo.num_heap_tuples issue.
> >
> > * Restored _bt_getbuf() page-from-FSM XID check. Out of sheer paranoia.
> >
> > * The second patch in the series now respects work_mem when sizing the
> > BTPendingRecycle array.
> >
> > * New enhancement to the XID GlobalVisCheckRemovableFullXid() test
> > used in the second patch, to allow it to recycle even more pages.
> > (Still unsure of some of the details here.)
>
> Thank you for updating the patch!
>
> >
> > I would like to commit the first patch in a few days -- I refer to the
> > big patch that makes deleted page XIDs 64-bit/full. Can you take a
> > look at that one, Masahiko? That would be helpful. I can produce a bug
> > fix for the IndexVacuumInfo.num_heap_tuples issue fairly easily, but I
> > think that that should be written after the first patch is finalized
> > and committed.
>
> I'll look at the first patch first.

The 0001 patch looks good to me. In the documentation, I think we need
to update the following paragraph in the description of
vacuum_cleanup_index_scale_factor:

If no tuples were deleted from the heap, B-tree indexes are still
scanned at the VACUUM cleanup stage when at least one of the following
conditions is met: the index statistics are stale, or the index
contains deleted pages that can be recycled during cleanup. Index
statistics are considered to be stale if the number of newly inserted
tuples exceeds the vacuum_cleanup_index_scale_factor fraction of the
total number of heap tuples detected by the previous statistics
collection. The total number of heap tuples is stored in the index
meta-page. Note that the meta-page does not include this data until
VACUUM finds no dead tuples, so B-tree index scan at the cleanup stage
can only be skipped if the second and subsequent VACUUM cycles detect
no dead tuples.

Regards,

--
Masahiko Sawada
EDB: https://www.enterprisedb.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira 2021-02-22 12:28:07 Re: row filtering for logical replication
Previous Message Thomas Munro 2021-02-22 11:30:18 Re: pg_collation_actual_version() ERROR: cache lookup failed for collation 123