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

Jamison, Kirk <k.jamison@jp.fujitsu.com>

From: "Jamison, Kirk" <k.jamison@jp.fujitsu.com>

To: 'Amit Kapila' <amit.kapila16@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>

Cc: Laurenz Albe <laurenz.albe@cybertec.at>, Tom Lane <tgl@sss.pgh.pa.us>, Fujii Masao <masao.fujii@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2019-01-17T00:42:14Z

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 Thu, Nov 15, 2018 at 2:30 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>>
>> On 2018-Nov-15, Laurenz Albe wrote:
>>
> > > This new option would not only mitigate the long shared_buffers 
> > > scan, it would also get rid of the replication conflict caused by 
> > > the AccessExclusiveLock taken during truncation, which is discussed 
> > > in 
> > > https://www.postgresql.org/message-id/c9374921e50a5e8fb1ecf04eb8c6eb
> > > c3%40postgrespro.ru and seems to be a more difficult problem than 
> > > anticipated.
> >
> > FWIW I was just reminded yesterday that the AEL-for-truncation has 
> > been diagnosed to be a severe problem in production, and with no other 
> > solution in sight, I propose to move forward with the stop-gap.

I just want to ask whether or not we could proceed with this approach for now and 
if it is possible that we could have this solution integrated before PG12 development ends?

Regards,
Kirk Jamison