MySQL Bugs: #44160: DataPage allocated but not logged

Bug #44160	DataPage allocated but not logged
Submitted:	8 Apr 2009 16:58	Modified:	8 Apr 2009 21:31
Reporter:	Vladislav Vaintroub	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Falcon storage engine	Severity:	S3 (Non-critical)
Version:		OS:	Any
Assigned to:	Vladislav Vaintroub	CPU Architecture:	Any

Description:
In Section::storeRecord, there is a place where data page is allocated.
The corresponding serial log message is written to serial log only
conditionally ,if earlyWrite flag is not set.

This is suspect and very likely a subtle bug, since otherwise we do log allocations (and even do that while before releasing the page).

How to repeat:
Inspect source code

Suggested fix:
unconditionally log data page allocation

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/71669

3108 Vladislav Vaintroub	2009-04-08
      Bug #44160 DataPage allocated but not logged 
      
      The problem is that logging a data page is conditional , e.g not done when earlyWrite flag is set
      (big blobs). This is an irregularity and likely a subtle bug. We log all page allocations in other 
      situations and expect recovery do redo them.
       
      Fix is to unconditionally log the data page directly after the allocation.

Please do not push this patch. 

Ann wrote;
> The earlyWrite flag indicates that a DataPage is 
> actually a large blob page.  It's allocation should 
> not be recorded in the serial log because it will be 
> written directly to disk on commit without going 
> through the serial log.

If this page is logged, what would be the result of redoing it in the serial log?  It is questionable if this is needed, but does it make the recovery more robust by checking the existence of this blob page that should already be in the database file?  Please explain what would happen by logging a page that is written directly.

There are two cases.  If the transaction that created the blob is committed,
that blob page is on disk and marked as in use on the PIP.  When it's reallocated
during recovery, the bit that's already set in the PIP will be reset.  If the
transaction did not commit before the crash, recovery will mark the page as 
in use on the PIP, and it will an orphan page - nothing will release it.

generally, page allocations need to be recorded for recovery to reset everything to the same state as it was before crash.

If page allocations are not redone, pages can be marked free in PIP and some other page will be reallocated on the same place in the phase 3 of recovery.
Besides, a page allocation sometimes includes more than just marking a bit in PIP. Sometimes different meta-"parent" structures (Sections etc) need to be correctly setup when a page is allocated. Recovery will redo that.

Maybe it does not apply to this case, but from the first short inspection I do not see why. The page is not lost from PIP, its incarnations are bumped and as side effect pip is marked, but the content of it (incl. header with page type) can be just anything.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/71687

3108 Vladislav Vaintroub	2009-04-08
      Bug #44160 DataPage allocated but not logged 
      
      Added comment clarifying why the page should not be logged

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/71688

3108 Vladislav Vaintroub	2009-04-08
      Bug #44160 DataPage allocated but not logged 
      
      Added comment clarifying why the page should not be logged

was just an confusing place in the source.
Fixed by writing a comment

Pushed into 6.0.11-alpha (revid:hky@sun.com-20090415164923-9arx29ye5pzxd4zf) (version source revid:vvaintroub@mysql.com-20090408212714-40iztk8xy9204ttm) (merge vers: 6.0.11-alpha) (pib:6)