Idea for better handling of cntxDirty - Mailing list pgsql-hackers

From Tom Lane
Subject Idea for better handling of cntxDirty
Date
Msg-id 20057.1037065899@sss.pgh.pa.us
Whole thread Raw
List pgsql-hackers
Vadim,

In LockBuffer() you wrote
   else if (mode == BUFFER_LOCK_EXCLUSIVE)   {       LWLockAcquire(buf->cntx_lock, LW_EXCLUSIVE);
       /*        * This is not the best place to set cntxDirty flag (eg indices do        * not always change buffer
theylock in excl mode). But please        * remember that it's critical to set cntxDirty *before* logging        *
changeswith XLogInsert() - see comments in BufferSync().        */       buf->cntxDirty = true;   }
 

The comments in BufferSynx are
       /*        * We can check bufHdr->cntxDirty here *without* holding any lock        * on buffer context as long as
weset this flag in access methods        * *before* logging changes with XLogInsert(): if someone will set        *
cntxDirtyjust after our check we don't worry because of our        * checkpoint.redo points before log record for
upcomingchanges        * and so we are not required to write such dirty buffer.        */
 

Wouldn't it work for cntxDirty to be set not by LockBuffer, but by
XLogInsert for each buffer that is included in its argument list?
This would avoid setting the flag for pages that are not modified
after being locked.  XLogInsert would of course set the flag before
doing the actual WAL insertion, so it seems to me that the condition
we want is met, and we still have only a single place that needs to
remember to set the flag.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 500 tpsQL + WAL log implementation
Next
From: Kris Jurka
Date:
Subject: Unique functional index and FK constraints