RE: reloption to prevent VACUUM from truncating empty pages at theend of relation - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: reloption to prevent VACUUM from truncating empty pages at theend of relation
Date
Msg-id 0A3221C70F24FB45833433255569204D1FBF2EBA@G01JPEXMBYT05
Whole thread Raw
In response to Re: reloption to prevent VACUUM from truncating empty pages at theend of relation  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
List pgsql-hackers
From: Alvaro Herrera [mailto:alvherre@2ndquadrant.com]
> "vacuum_truncate" gets my vote too.

+1


From: 'Andres Freund' [mailto:andres@anarazel.de]
> Personally I think the name just needs some committer to make a
> call. This largely is going to be used after encountering too many
> cancellations in production, and researching the cause. Minor spelling
> differences don't seem to particularly matter here.

Absolutely.  Thank you.


From: 'Andres Freund' [mailto:andres@anarazel.de]
> I think it needs to be an autovac option. The production issue is that
> autovacuums constantly cancel queries on the standbys despite
> hot_standby_feedback if you have a workload that does frequent
> truncations. If there's no way to configure it in a way that autovacuum
> takes it into account, people will just disable autovacuum and rely
> entirely on manual scripts. That's what already happens - leading to a
> much bigger foot-gun than disabling truncation.  FWIW, people already in
> production use the workaround to configuring snapshot_too_old as that,
> for undocumented reasons, disables trunctations. That's not better
> either.

Right.  We don't want autovacuum to be considered as a criminal.


Regards
Takayuki Tsunakawa



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Ordered Partitioned Table Scans
Next
From: Michael Paquier
Date:
Subject: Re: change password_encryption default to scram-sha-256?