Postgres Pro
Downloads
Home   >   mailing lists

Improve the performance to create END_OF_RECOVERY checkpoint - Mailing list pgsql-hackers

From Thunder
Subject Improve the performance to create END_OF_RECOVERY checkpoint
Date
Msg-id 104e675c.41b1.176896de1d9.Coremail.thunder1@126.com
Whole thread Raw
Responses RE: Improve the performance to create END_OF_RECOVERY checkpoint
List pgsql-hackers
Tree view
Dear All

In startup process we only launch bgwriter when ArchiveRecoveryRequested is true, which means we will not lauch bgwriter in master node.
The bgwriters can write the dirty buffers to disk which helps startup process to do less IO when we complete xlog replay and request to do END_OF_RECOVERY checkpoint.
So can we delete the limit of ArchiveRecoveryRequested, and enable launch bgwriter in master node ?

   7128         /*
   7129          * Let postmaster know we've started redo now, so that it can launch
   7130          * checkpointer to perform restartpoints.  We don't bother during
   7131          * crash recovery as restartpoints can only be performed during
   7132          * archive recovery.  And we'd like to keep crash recovery simple, to
   7133          * avoid introducing bugs that could affect you when recovering after
   7134          * crash.
   7135          *
   7136          * After this point, we can no longer assume that we're the only
   7137          * process in addition to postmaster!  Also, fsync requests are
   7138          * subsequently to be handled by the checkpointer, not locally.
   7139          */
   7140         if (ArchiveRecoveryRequested && IsUnderPostmaster)
   7141         {
   7142             PublishStartupProcessInformation();
   7143             EnableSyncRequestForwarding();
   7144             SendPostmasterSignal(PMSIGNAL_RECOVERY_STARTED);
   7145             bgwriterLaunched = true;
   7146         }

Thanks
Ray


 

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: a misbehavior of partition row movement (?)
Next
From: Amit Langote
Date:
Subject: Re: a misbehavior of partition row movement (?)