Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)
От | Fujii Masao |
---|---|
Тема | Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock) |
Дата | |
Msg-id | CAHGQGwEENzaeJr-OeXEtbGQUy4UcB8NbnPu-xAwZqumuyQ1_qQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock) (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Scaling XLog insertion (was Re: Moving more work outside
WALInsertLock)
|
Список | pgsql-hackers |
On Mon, Feb 13, 2012 at 8:37 PM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: > On 13.02.2012 01:04, Jeff Janes wrote: >> >> Attached is my quick and dirty attempt to set XLP_FIRST_IS_CONTRECORD. >> I have no idea if I did it correctly, in particular if calling >> GetXLogBuffer(CurrPos) twice is OK or if GetXLogBuffer has side >> effects that make that a bad thing to do. I'm not proposing it as the >> real fix, I just wanted to get around this problem in order to do more >> testing. > > > Thanks. That's basically the right approach. Attached patch contains a > cleaned up version of that. Got another problem: when I ran pg_stop_backup to take an online backup, it got stuck until I had generated new WAL record. This happens because, in the patch, when pg_stop_backup forces a switch to new WAL file, old WAL file is not marked as archivable until next new WAL record has been inserted, but pg_stop_backup keeps waiting for that WAL file to be archived. OTOH, without the patch, WAL file is marked as archivable as soon as WAL file switch occurs. So, in short, the patch seems to handle the WAL file switch logic incorrectly. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: