PostgreSQL 15 preview - Wake up for latches in CheckpointWriteDelay()

原创 digoal 2022-01-20

390

作者

digoal

日期

2022-03-16

Wake up for latches in CheckpointWriteDelay().   
author  Thomas Munro <tmunro@postgresql.org>      
Wed, 16 Mar 2022 00:37:58 +0000 (13:37 +1300)  
committer   Thomas Munro <tmunro@postgresql.org>      
Wed, 16 Mar 2022 00:57:59 +0000 (13:57 +1300)  
commit  5e6368b42ee6d4b59e085301ca7b0e50f37a897b  
tree    770884f4f9157bb286c3b86d6f7aa2040ab2d5ce    tree  
parent  a56e7b66010f330782243de9e25ac2a6596be0e1    commit | diff  
Wake up for latches in CheckpointWriteDelay().  
The checkpointer shouldn't ignore its latch.  Other backends may be  
waiting for it to drain the request queue.  Hopefully real systems don't  
have a full queue often, but the condition is reached easily when  
shared_buffers is small.  
This involves defining a new wait event, which will appear in the  
pg_stat_activity view often due to spread checkpoints.  
Back-patch only to 14.  Even though the problem exists in earlier  
branches too, it's hard to hit there.  In 14 we stopped using signal  
handlers for latches on Linux, *BSD and macOS, which were previously  
hiding this problem by interrupting the sleep (though not reliably, as  
the signal could arrive before the sleep begins; precisely the problem  
latches address).  
Reported-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/20220226213942.nb7uvb2pamyu26dj%40alap3.anarazel.de

/*  
 678  * CheckpointWriteDelay -- control rate of checkpoint  
 679  *  
 680  * This function is called after each page write performed by BufferSync().  
 681  * It is responsible for throttling BufferSync()'s write rate to hit  
 682  * checkpoint_completion_target.  
 683  *  
 684  * The checkpoint request flags should be passed in; currently the only one  
 685  * examined is CHECKPOINT_IMMEDIATE, which disables delays between writes.  
 686  *  
 687  * 'progress' is an estimate of how much of the work has been done, as a  
 688  * fraction between 0.0 meaning none, and 1.0 meaning all done.  
 689  */  
 690 void  
 691 CheckpointWriteDelay(int flags, double progress)  
 692 {  
 693     static int  absorb_counter = WRITES_PER_ABSORB;  
 694   
 695     /* Do nothing if checkpoint is being executed by non-checkpointer process */  
 696     if (!AmCheckpointerProcess())  
 697         return;  
 698   
 699     /*  
 700      * Perform the usual duties and take a nap, unless we're behind schedule,  
 701      * in which case we just try to catch up as quickly as possible.  
 702      */  
 703     if (!(flags & CHECKPOINT_IMMEDIATE) &&  
 704         !ShutdownRequestPending &&  
 705         !ImmediateCheckpointRequested() &&  
 706         IsCheckpointOnSchedule(progress))  
 707     {  
 708         if (ConfigReloadPending)  
 709         {  
 710             ConfigReloadPending = false;  
 711             ProcessConfigFile(PGC_SIGHUP);  
 712             /* update shmem copies of config variables */  
 713             UpdateSharedMemoryConfig();  
 714         }  
 715   
 716         AbsorbSyncRequests();  
 717         absorb_counter = WRITES_PER_ABSORB;  
 718   
 719         CheckArchiveTimeout();  
 720   
 721         /*  
 722          * Report interim activity statistics.  
 723          */  
 724         pgstat_send_checkpointer();  
 725   
 726         /*  
 727          * This sleep used to be connected to bgwriter_delay, typically 200ms.  
 728          * That resulted in more frequent wakeups if not much work to do.  
 729          * Checkpointer and bgwriter are no longer related so take the Big  
 730          * Sleep.  
 731          */  
 732         WaitLatch(MyLatch, WL_LATCH_SET | WL_EXIT_ON_PM_DEATH | WL_TIMEOUT,  
 733                   100,  
 734                   WAIT_EVENT_CHECKPOINT_WRITE_DELAY);  
 735         ResetLatch(MyLatch);  
 736     }