Re: REPACK enhancements

From: Antonin Houska <ah(at)cybertec(dot)at>
To: shihao zhong <zhong950419(at)gmail(dot)com>
Cc: alvherre(at)kurilemu(dot)de, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: REPACK enhancements
Date: 2026-09-18 18:38:06
Message-ID: 21489.1789756686@localhost
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Antonin Houska <ah(at)cybertec(dot)at> wrote:

> shihao zhong <zhong950419(at)gmail(dot)com> wrote:
>
> > 2.
> > Looks like some rows are lost when the table grows/gap fill.
> >
> > heapScan->rs_nblocks is fixed when the scan starts. At a range boundary,
> > changes to blocks at or beyond rs_nblocks are not in [range_start, range_end),
> > so they are skipped. The next snapshot can see those tuples, but the scan never
> > reaches those blocks.
> >
> > The attached extend.spec has 5 blocks. It uses
> > repack_snapshot_after = 2, pauses at the first boundary, and inserts 100
> > rows. 70 of them go to blocks 5 to 7 and are missing after REPACK.
>
> Interestiong. I think we need to get the new rows from new blocks each time we
> process the concurrent changes.

I could spend a little while on this item. Attached is what fixes your
extend.spec.text.

--
Antonin Houska
Web: https://www.cybertec-postgresql.com

Attachment Content-Type Size
nocfbot.do_not_miss_relation_extension.diff text/x-diff 9.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2026-09-18 18:56:26 Re: pgoutput: schema cache cleanup after streamed 2PC
Previous Message Masahiko Sawada 2026-09-18 18:37:02 Re: [PATCH] Release replication slot on error in SQL-callable slot functions