Re: Freeze avoidance of very large table.

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Greg S <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Freeze avoidance of very large table.
Date: 2016-03-10 06:27:09
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

Thank you for reviewing!
Attached updated patch.

On Thu, Mar 10, 2016 at 3:37 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Mar 9, 2016 at 9:09 AM, Masahiko Sawada
> <sawada(dot)mshk(at)gmail(dot)com> wrote: Attached latest 2 patches.
>> * 000 patch : Incorporated the review comments and made rewriting
>> logic more clearly.
> That's better, thanks. But your comments don't survive pgindent.
> After running pgindent, I get this:
> + /*
> + * These old_* variables point to old visibility map page.
> + *
> + * cur_old : Points to current position on old
> page. blkend_old :
> + * Points to end of old block. break_old : Points to
> old page break
> + * position for rewriting a new page. After wrote a
> new page, old_end
> + * proceeds rewriteVmBytesPerPgae bytes.
> + */
> You need to either surround this sort of thing with dashes to make
> pgindent ignore it, or, probably better, rewrite it using complete
> sentences that together form a paragraph.


> + Oid pg_database_oid; /* OID of
> pg_database relation */
> Not used anywhere?


> Instead of vm_need_rewrite, how about vm_must_add_frozenbit?


> Can you explain the changes to

Current regression test scenario is,
1. Do 'make check' on pre-upgrade cluster
2. Dump relallvisible values of all relation in pre-upgrade cluster to
3. Do pg_upgrade
4. Do analyze (not vacuum), dump relallvisibile values of all relation
in post-upgrade cluster to vm_test2.txt
5. Compare between vm_test1.txt and vm_test2.txt

That is, regression test compares between relallvisible values in
pre-upgrade cluster and post-upgrade cluster.
But because always uses pre/post clusters with same catalog
version, I realized that we cannot ensure that visibility map
rewriting is processed successfully on framework.
Rewriting visibility map never be executed.
We might need to have another framework for rewriting visibility map page..


Masahiko Sawada

Attachment Content-Type Size
000_pgupgrade_rewrite_vm_v39.patch application/x-patch 11.2 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-03-10 06:27:34 Re: Improving replay of XLOG_BTREE_VACUUM records
Previous Message Michael Paquier 2016-03-10 06:24:06 Re: BUG #13755: pgwin32_is_service not checking if SECURITY_SERVICE_SID is disabled