On Mon, Nov 21, 2016 at 11:08 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Tue, Nov 15, 2016 at 9:59 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> On Tue, Nov 15, 2016 at 9:27 AM, Kyotaro HORIGUCHI >> <horiguchi.kyot...@lab.ntt.co.jp> wrote: >>> The term "WAL activity' is used in the comment for >>> GetProgressRecPtr. Its meaning is not clear but not well >>> defined. Might need a bit detailed explanation about that or "WAL >>> activity tracking". What do you think about this? >>> >> >> I would have written it as below: >> >> GetProgressRecPtr -- Returns the WAL progress. WAL progress is >> determined by scanning each WALinsertion lock by taking directly the >> light-weight lock associated to it. > > Not sure if that's better.. What about something as fancy as that? > /* > - * Get the time of the last xlog segment switch > + * GetProgressRecPtr -- Returns the newest WAL progress position. WAL > + * progress is determined by scanning each WALinsertion lock by taking > + * directly the light-weight lock associated to it. The result of this > + * routine can be compared with the last checkpoint LSN to check if > + * a checkpoint can be skipped or not. > + * > It may be worth mentioning that the result of this routine is > basically used for checkpoint skip logic. >
That's okay, but I think you are using it to skip switch segment stuff as well. Today, again going through patch, I noticed small anomaly > + * Switch segment only when WAL has done some progress since the + * > last time a segment has switched because of a timeout. > + if (GetProgressRecPtr() > last_switch_lsn) Either the above comment is wrong or the code after it has a problem. last_switch_lsn aka XLogCtl->lastSegSwitchLSN is updated not only for a timeout but also when there is a lot of WAL activity which makes WAL Write to cross a segment boundary. -- With Regards, Amit Kapila. 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
