Hi, On 2019-04-08 00:38:44 -0400, Tom Lane wrote: > "Tsunakawa, Takayuki" <tsunakawa.ta...@jp.fujitsu.com> writes: > > From: Tom Lane [mailto:t...@sss.pgh.pa.us] > >> And, as far as I can see from a quick review of the thread, > >> we don't really have consensus on the names and behaviors.
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. > My own dog in this fight is that we shouldn't have the option at all, > never mind what the name is. A persistent reloption to disable truncation > seems like a real foot-gun. I'd be okay with a VACUUM command option, > but for some reason that isn't there at all. 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. Greetings, Andres Freund
