Re: XLogInsert scaling, revisited

On 17.07.2013 02:18, Michael Paquier wrote:
> On Tue, Jul 16, 2013 at 2:24 AM, Fujii Masao<masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Mon, Jul 8, 2013 at 6:16 PM, Heikki Linnakangas
>> <hlinnakangas(at)vmware(dot)com> wrote:
>>> Ok, I've committed this patch now. Finally, phew!
>>
>> I found that this patch causes the assertion failure. When I set up simple
>> replication environment and promoted the standby before executing any
>> transaction on the master, I got the following assertion failure.
>>
>> 2013-07-16 02:22:06 JST sby1 LOG: received promote request
>> 2013-07-16 02:22:06 JST sby1 FATAL: terminating walreceiver process
>> due to administrator command
>> 2013-07-16 02:22:06 JST sby1 LOG: redo done at 0/20000F0
>> 2013-07-16 02:22:06 JST sby1 LOG: selected new timeline ID: 2
>> hrk:head-pgsql postgres$ 2013-07-16 02:22:06 JST sby1 LOG: archive
>> recovery complete
>> TRAP: FailedAssertion("!(readOff == (XLogCtl->xlblocks[firstIdx] -
>> 8192) % ((uint32) (16 * 1024 * 1024)))", File: "xlog.c", Line: 7048)
>> 2013-07-16 02:22:12 JST sby1 LOG: startup process (PID 37115) was
>> terminated by signal 6: Abort trap
>> 2013-07-16 02:22:12 JST sby1 LOG: terminating any other active server processes
> Note that this is also reproducible even when trying to recover only
> from archives without strrep.

Fixed, thanks for the report. While at it, I slightly refactored the way
the buffer bookkeeping works. Instead of keeping track of the index of
the last initialized buffer, keep track how far the buffer cache has
been initialized in an XLogRecPtr variable (called
XLogCtl->InitializedUpTo). That made the code slightly more readable IMO.

- Heikki