Hi,
On 2019-04-08 00:38:44 -0400, Tom Lane wrote:
> "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com> writes:
> > From: Tom Lane [mailto:tgl@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