| 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 |
| 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 |