On 16.02.2012 13:31, Fujii Masao wrote:
On Thu, Feb 16, 2012 at 6:15 PM, Fujii Masao<masao.fu...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
