Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility
От | Heikki Linnakangas |
---|---|
Тема | Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility |
Дата | |
Msg-id | d190140f-b6e8-5e2f-c663-c8f9617da18e@iki.fi обсуждение исходный текст |
Ответ на | Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility (Chapman Flack <chap@anastigmatix.net>) |
Ответы |
Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility
|
Список | pgsql-hackers |
On 07/03/2017 06:30 PM, Chapman Flack wrote: > On 07/03/2017 09:39 AM, Heikki Linnakangas wrote: > >> Hmm. That's not the problem, though. Imagine that instead of the loop >> above, you do just: >> >> WALInsertLockUpdateInsertingAt(CurrPos); >> AdvanceXLInsertBuffer(EndPos, false); >> >> AdvanceXLInsertBuffer() will call XLogWrite(), to flush out any pages >> before EndPos, to make room in the wal_buffers for the new pages. Before >> doing that, it will call WaitXLogInsertionsToFinish() > > Although it's moot in the straightforward approach of re-zeroing in > the loop, it would still help my understanding of the system to know > if there is some subtlety that would have broken what I proposed > earlier, which was an extra flag to AdvanceXLInsertBuffer() that > would tell it not only to skip initializing headers, but also to > skip the WaitXLogInsertionsToFinish() check ... because I have > the entire region reserved and I hold all the writer slots > at that moment, it seems safe to assure AdvanceXLInsertBuffer() > that there are no outstanding writes to wait for. Yeah, I suppose that would work, too. - Heikki
В списке pgsql-hackers по дате отправления: