From: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: FSM corruption leading to errors |
Date: | 2016-10-20 05:50:40 |
Message-ID: | CABOikdPC3bGk9x9qFEDBhgccqECOyNFxjo=gN9w247D-GoKb9g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | Postg스포츠 토토 사이트SQL |
On Thu, Oct 20, 2016 at 10:50 AM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com
> wrote:
>
> For VMs a good way would
> be to use pg_visibility's pg_truncate_visibility_map(), but only for
> 9.6~.
Ah ok..
> For FSM there is no real solution, and actually a
> pg_truncate_fsm would prove to be useful here.
Right, that's what I proposed as an alternate idea. I agree this is much
cleaner and less error prone approach.
Actually, if we could add an API which can truncate FSM to the given heap
block, then the user may not even need to run VACUUM, which could be costly
for very large tables. Also, AFAICS we will need to backport
pg_truncate_visibility_map() to older releases because unless the VM is
truncated along with the FSM, VACUUM may not scan all pages and the FSM for
those pages won't be recorded.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-10-20 06:04:02 | Re: FSM corruption leading to errors |
Previous Message | Michael Paquier | 2016-10-20 05:20:54 | Re: FSM corruption leading to errors |