| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Amit Kapila <akapila(at)postgresql(dot)org>, pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pgsql: Revert "Avoid the creation of the free space map for small heap |
| Date: | 2019-05-07 04:33:24 |
| Message-ID: | CAA4eK1KHeOeQfxOFyCjrYY4p7FZBRQtMwHLDGC-w5Zy32LDNcg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
On Tue, May 7, 2019 at 9:51 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> > On Tue, May 7, 2019 at 9:44 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Shouldn't there be a catversion bump in this?
>
> > Won't the next vacuum run will create the FSM?
>
> If that's true, and if we don't throw any errors meanwhile, it's fine.
>
This is what is suppose to happen.
> I'm just worried that that's an untested scenario.
>
I can test it. Basically, without revert of the patch, I can create a
table with a few records (so as to ensure that there is no FSM). And
then revert the patch and upgrade the database and perform few dml
operations on that table and see what happens?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2019-05-07 05:22:03 | pgsql: Remove some code related to 7.3 and older servers from tools of |
| Previous Message | Tom Lane | 2019-05-07 04:21:04 | Re: pgsql: Revert "Avoid the creation of the free space map for small heap |