| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, 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-25 05:21:54 |
| Message-ID: | CAH2-WzmLjc+sregqUCkr+jVvE_MgsTA0cMOTqoGAN=CiZGPxGw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Feb 24, 2021 at 8:13 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> I think 8e12f4a25 wasn't quite aggressive enough in its changes, and I had
> another patch laying around. I rebased and came up with this.
See my remarks/questions about vacuum_cleanup_index_scale_factor
addressed to Masahiko from a little earlier. I think that it might
make sense to just remove it. It might even make sense to disable it
in the backbranches -- that approach might be better than trying to
fix the "IndexVacuumInfo.num_heap_tuples is only representative of the
heap relation at the end of the VACUUM when considered within
btvacuumcleanup()" bug. (Though I'm less confident on this second
point about a backpatchable fix.)
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | wangsh.fnst@fujitsu.com | 2021-02-25 06:07:06 | RE: BUG #15858: could not stat file - over 4GB |
| Previous Message | Amit Kapila | 2021-02-25 04:52:41 | Re: Single transaction in the tablesync worker? |