Re: logical decoding vs. VACUUM FULL / CLUSTER on table with TOAST-eddata
От | Tomas Vondra |
---|---|
Тема | Re: logical decoding vs. VACUUM FULL / CLUSTER on table with TOAST-eddata |
Дата | |
Msg-id | db178c55-18cb-fc0c-6a16-a971ae9a9806@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: logical decoding vs. VACUUM FULL / CLUSTER on table withTOAST-ed data (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On 11/28/18 3:31 AM, Andres Freund wrote: > Hi, > > On 2018-11-28 03:06:58 +0100, Petr Jelinek wrote: >> On 28/11/2018 02:14, Andres Freund wrote: >>> On 2018-11-28 02:04:18 +0100, Tomas Vondra wrote: >>>> Pushed and backpatched to 9.4- (same as e9edc1ba). >>> >>> Backpatching seems on the more aggressive end of things for an >>> optimization. Could you at least announce that beforehand next time? >>> >> >> Well, it may be optimization, but from what I've seen the problems >> arising from this can easily prevent logical replication from working >> altogether as reorder buffer hits OOM on bigger tables. So ISTM that it >> does warrant backpatch. > > I think that's a fair argument to be made. But it should be made > both before the commit and in the commit message. > Understood. I thought I stated the intent to backpatch when announcing I'll push it this week, but clearly that did not happen. Oops :-( That being said, I see this more like a bugfix than an optimization, because (as Petr already stated) rewrite of any sufficiently large table can irreparably break the replication. So it's not just slower, it dies. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: