RE: reloption to prevent VACUUM from truncating empty pages at theend of relation
От | Tsunakawa, Takayuki |
---|---|
Тема | RE: reloption to prevent VACUUM from truncating empty pages at theend of relation |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1FBF2EBA@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | Re: reloption to prevent VACUUM from truncating empty pages at theend of relation (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
|
Список | 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 по дате отправления: