Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

Julien Rouhaud <rjuju123@gmail.com>

From: Julien Rouhaud <rjuju123@gmail.com>

To: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>

Cc: Michael Paquier <michael@paquier.xyz>, Laurenz Albe <laurenz.albe@cybertec.at>, "Jamison, Kirk" <k.jamison@jp.fujitsu.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Amit Kapila <amit.kapila16@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Fujii Masao <masao.fujii@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2019-02-22T09:24:32Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Add TRUNCATE parameter to VACUUM.
- b84dbc8eb80b 12.0 landed
Add vacuum_truncate reloption.
- 119dcfad988d 12.0 landed
Allow VACUUM to be run with index cleanup disabled.
- a96c41feec6b 12.0 cited

On Fri, Feb 22, 2019 at 3:39 AM Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.com> wrote:
>
> No, changing the parameter acquires ShareUpdaeExclusive lock.  I just imitated the description for n_distinct in the same comment block.  The meaning is that the setting cannot be changed during VACUUM, so in-flight VACUUM is not affected.

Ah I see, thanks!  I find this a little bit confusing but if that's
already documented like this for other parameters then I guess that's
ok.

One last thing, I think we should at least add one regression test for
this setting.  The one you provided previously seems perfectly suited.