db/pgbackrest
1
0
Fork 0
mirror of https://github.com/pgbackrest/pgbackrest.git synced 2025-02-03 13:21:32 +02:00
Code Issues Releases Activity

Remove double spaces missed in 1bd5530a.

Browse Source
This commit is contained in:
David Steele 2023-05-03 09:37:59 +03:00
parent efac3474cf
commit d49907239e
5 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/xml/contributing.xml
View File

@ -632,9 +632,9 @@ run 8/1 ------------- L2285 no current backups
<p><b>run 8/1 ------------- L2285 no current backups</b> - this is the first test (1) in run 8 which is the <code>TEST_TITLE("no current backups");</code> at line number 2285.</p>
<p><b>000.002s L2298 empty backup.info</b> - the first number, 000.002s, is the time in seconds that the test started from the beginning of the run. L2298 is the line number of the test and <code>empty backup.info</code> is the test comment.</p>
<p><b>000.002s L2298 empty backup.info</b> - the first number, 000.002s, is the time in seconds that the test started from the beginning of the run. L2298 is the line number of the test and <code>empty backup.info</code> is the test comment.</p>
<p><b>000.009s 000.007s L2300 no backups to expire</b> - again, 000.009s, is the time in seconds that the test started from the beginning of the run. The second number, 000.007s, is the run time of the <b>previous</b> test (i.e. <code>empty backup.info</code> test took 000.007 seconds to execute). L2300 is the line number of the test and <code>no backups to expire</code> is the test comment.</p>
<p><b>000.009s 000.007s L2300 no backups to expire</b> - again, 000.009s, is the time in seconds that the test started from the beginning of the run. The second number, 000.007s, is the run time of the <b>previous</b> test (i.e. <code>empty backup.info</code> test took 000.007 seconds to execute). L2300 is the line number of the test and <code>no backups to expire</code> is the test comment.</p>
</section>
</section>

2
doc/xml/documentation.xml
View File

@ -78,7 +78,7 @@ sudo usermod -aG docker testdoc
<p>RHEL 7:</p>
<code-block type="bash">
./doc.pl --out=html --include=user-guide --no-cache --var=os-type=rhel --var=os-image=centos:7 --var=package=test/package/pgbackrest-2.08-1.el7.x86_64.rpm
./doc.pl --out=html --include=user-guide --no-cache --var=os-type=rhel --var=os-image=centos:7 --var=package=test/package/pgbackrest-2.08-1.el7.x86_64.rpm
</code-block>
<p>RHEL 8:</p>

2
doc/xml/dtd/doc.dtd
View File

@ -53,7 +53,7 @@
<!ATTLIST execute-list host CDATA #REQUIRED>
<!ATTLIST execute-list if CDATA "">
<!ATTLIST execute-list show CDATA "">
<!ELEMENT execute (exe-cmd, exe-cmd-extra?, exe-user?, exe-var?, exe-retry?, exe-output?, (exe-highlight-type?, exe-highlight)?,
<!ELEMENT execute (exe-cmd, exe-cmd-extra?, exe-user?, exe-var?, exe-retry?, exe-output?, (exe-highlight-type?, exe-highlight)?,
exe-err-expect?, exe-err-suppress?, exe-err-suppress-stderr?)>
<!ATTLIST execute if CDATA "">
<!ATTLIST execute pre CDATA "">

4
doc/xml/faq.xml
View File

@ -86,7 +86,7 @@ process-max=1
<section id="backup-standby">
<title>Why does a backup attempt fail when <br-option>backup-standby=y</br-option> and the standby database is down?</title>
<p>Configuring backup from standby is generally intended to reduce load on the primary, so switching backups to the primary when the standby is down often defeats the point. Putting more load on the primary in a situation where there are already failures in the system is not recommended. Backups are not critical as long as you have one that is fairly recent -- the important thing is to keep up with WAL archiving. There is plenty of time to get a backup when the system is stable again.</p>
<p>Configuring backup from standby is generally intended to reduce load on the primary, so switching backups to the primary when the standby is down often defeats the point. Putting more load on the primary in a situation where there are already failures in the system is not recommended. Backups are not critical as long as you have one that is fairly recent -- the important thing is to keep up with WAL archiving. There is plenty of time to get a backup when the system is stable again.</p>
<p>If you really need a backup, the solution is to have more standbys or remove <br-option>backup-standby</br-option>. This can be overridden on the command line with <br-option>--no-backup-standby</br-option>, so there is no need to reconfigure for a one-off backup.</p>
</section>
@ -157,6 +157,6 @@ process-max=1
<!-- <section id="SOMETHING">
<title>SOMETHING</title>
<p>Issue 610 - has come up a couple times, so distill it and point to this as a resource https://github.com/pgbackrest/pgbackrest/issues/610</p>
<p>Issue 610 - has come up a couple times, so distill it and point to this as a resource https://github.com/pgbackrest/pgbackrest/issues/610</p>
</section> -->
</doc>

2
test/src/module/command/verifyTest.c
View File

@ -1560,7 +1560,7 @@ testRun(void)
.comment = "valid manifest copy - full");
HRN_STORAGE_PUT_Z(
storageRepoWrite(), STORAGE_REPO_BACKUP "/20201119-163000F/bundle/1", zNewFmt("XXX%s", fileContents),
storageRepoWrite(), STORAGE_REPO_BACKUP "/20201119-163000F/bundle/1", zNewFmt("XXX%s", fileContents),
.comment = "valid file");
// Create WAL file with just header info and small WAL size