Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Jeff Janes <jeff.janes@gmail.com>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2012-02-17T08:59:19Z
Lists: pgsql-hackers
On 16.02.2012 13:31, Fujii Masao wrote:
> On Thu, Feb 16, 2012 at 6:15 PM, Fujii Masao<masao.fujii@gmail.com>  wrote:
>> BTW, when I ran the test on my Ubuntu, I could not reproduce the problem.
>> I could reproduce the problem only in MacOS.
>
> +	nextslot = Insert->nextslot;
> +	if (NextSlotNo(nextslot) == lastslot)
> +	{
> +		/*
> +		 * Oops, we've "caught our tail" and the oldest slot is still in use.
> +		 * Have to wait for it to become vacant.
> +		 */
> +		SpinLockRelease(&Insert->insertpos_lck);
> +		WaitForXLogInsertionSlotToBecomeFree();
> +		goto retry;
> +	}
> +	myslot =&XLogCtl->XLogInsertSlots[nextslot];
> +	nextslot = NextSlotNo(nextslot);
>
> nextslot can reach NumXLogInsertSlots, which would be a bug, I guess.
> When I did the quick-fix and ran the test, I could not reproduce the problem
> any more. I'm not sure if this is really the cause of the problem, though.

Ah, I see. That explains why you only see it on some platforms - 
depending on ALIGNOF_XLOG_BUFFER, there is often enough padding after 
the last valid slot to accommodate the extra bogus slot. Thanks for the 
debugging!

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com