Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
От | 'Andres Freund' |
---|---|
Тема | Re: reloption to prevent VACUUM from truncating empty pages at theend of relation |
Дата | |
Msg-id | 20190408044345.ndxsnveqqlj3m67g@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: reloption to prevent VACUUM from truncating empty pages at the end of relation (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: