|
655 | 655 | directory.
|
656 | 656 | Restartpoints can't be performed more frequently than checkpoints on the
|
657 | 657 | primary because restartpoints can only be performed at checkpoint records.
|
658 |
| - A restartpoint is triggered when a checkpoint record is reached if at |
659 |
| - least <varname>checkpoint_timeout</varname> seconds have passed since the last |
660 |
| - restartpoint, or if WAL size is about to exceed |
661 |
| - <varname>max_wal_size</varname>. However, because of limitations on when a |
662 |
| - restartpoint can be performed, <varname>max_wal_size</varname> is often exceeded |
663 |
| - during recovery, by up to one checkpoint cycle's worth of WAL. |
| 658 | + A restartpoint can be demanded by a schedule or by an external request. |
| 659 | + The <structfield>restartpoints_timed</structfield> counter in the |
| 660 | + <link linkend="monitoring-pg-stat-checkpointer-view"><structname>pg_stat_checkpointer</structname></link> |
| 661 | + view counts the first ones while the <structfield>restartpoints_req</structfield> |
| 662 | + the second. |
| 663 | + A restartpoint is triggered by schedule when a checkpoint record is reached |
| 664 | + if at least <xref linkend="guc-checkpoint-timeout"/> seconds have passed since |
| 665 | + the last performed restartpoint or when the previous attempt to perform |
| 666 | + the restartpoint has failed. In the last case, the next restartpoint |
| 667 | + will be scheduled in 15 seconds. |
| 668 | + A restartpoint is triggered by request due to similar reasons like checkpoint |
| 669 | + but mostly if WAL size is about to exceed <xref linkend="guc-max-wal-size"/> |
| 670 | + However, because of limitations on when a restartpoint can be performed, |
| 671 | + <varname>max_wal_size</varname> is often exceeded during recovery, |
| 672 | + by up to one checkpoint cycle's worth of WAL. |
664 | 673 | (<varname>max_wal_size</varname> is never a hard limit anyway, so you should
|
665 | 674 | always leave plenty of headroom to avoid running out of disk space.)
|
| 675 | + The <structfield>restartpoints_done</structfield> counter in the |
| 676 | + <link linkend="monitoring-pg-stat-checkpointer-view"><structname>pg_stat_checkpointer</structname></link> |
| 677 | + view counts the restartpoints that have really been performed. |
| 678 | + </para> |
| 679 | + |
| 680 | + <para> |
| 681 | + In some cases, when the WAL size on the primary increases quickly, |
| 682 | + for instance during massive INSERT, |
| 683 | + the <structfield>restartpoints_req</structfield> counter on the standby |
| 684 | + may demonstrate a peak growth. |
| 685 | + This occurs because requests to create a new restartpoint due to increased |
| 686 | + XLOG consumption cannot be performed because the safe checkpoint record |
| 687 | + since the last restartpoint has not yet been replayed on the standby. |
| 688 | + This behavior is normal and does not lead to an increase in system resource |
| 689 | + consumption. |
| 690 | + Only the <structfield>restartpoints_done</structfield> |
| 691 | + counter among the restartpoint-related ones indicates that noticeable system |
| 692 | + resources have been spent. |
666 | 693 | </para>
|
667 | 694 |
|
668 | 695 | <para>
|
|
0 commit comments