Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby
От | Michael Paquier |
---|---|
Тема | Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby |
Дата | |
Msg-id | CAB7nPqTrdQuDbsk2ngU-c7H7o5A-WotXu_BNdPD-9-rnHkkjQQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On Tue, Jan 19, 2016 at 1:28 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: > On Mon, Jan 18, 2016 at 7:08 PM, Andres Freund <andres@anarazel.de> wrote: >> I find this patch rather unsatisfactory. Yes, it kinda solves the >> problem of archive timeout, but it leaves the bigger and longer standing >> problems of unneccessary checkpoints with wal_level=hs in place. It's >> also somewhat fragile in my opinion. Check. >> I think we rather want a per backend (or perhaps per wal insertion lock) >> flag that says 'last relevant record inserted at', and a way to not set >> that during insertion. Then during a checkpoint or the relevant bgwriter >> code, we look wether anything relevant happened in any backend since the >> last time we performed a checkpoint/logged a running xacts snapshot. And in this case, the last relevant record would be caused by a forced segment switch or a checkpoint record, right? Doing that per WAL insertion lock seems more scalable to me. I haven't looked at the code yet though to see how that would work out. > Sounds to be a more robust way of dealing with this problem. Michael, > if you don't disagree with above proposal, then we can mark this patch > as Waiting on Author? Yeah let's do so. I'll think more about this thing. -- Michael
В списке pgsql-hackers по дате отправления: