Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file - Mailing list pgsql-hackers

From Martín Marqués
Subject Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file
Date
Msg-id CABeG9LviA01oHC5h=ksLUuhMyXxmZR_tftRq6q3341CMT=j=4g@mail.gmail.com
Whole thread Raw
In response to Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file  (David Steele <david@pgmasters.net>)
Responses Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file  (Michael Paquier <michael@paquier.xyz>)
Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Hi,

I was looking at the commit for this patch and noticed this small typo
in the comment in `basebackup.c`:

```
diff --git a/src/backend/replication/basebackup.c
b/src/backend/replication/basebackup.c
index 6884cad2c00af1632eacec07903098e7e1874393..815681ada7dd0c135af584ad5da2dd13c9a12465
100644 (file)
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -184,10 +184,8 @@ static const struct exclude_list_item excludeFiles[] =
    {RELCACHE_INIT_FILENAME, true},

    /*
-    * If there's a backup_label or tablespace_map file, it belongs to a
-    * backup started by the user with pg_start_backup().  It is *not* correct
-    * for this backup.  Our backup_label/tablespace_map is injected into the
-    * tar separately.
+    * backup_label and tablespace_map should not exist in in a running cluster
+    * capable of doing an online backup, but exclude them just in case.
     */
    {BACKUP_LABEL_FILE, false},
    {TABLESPACE_MAP, false},
```

The typo is in `exist in in a running cluster`. There's two `in` in a row.

P.D.: I was looking at this just because I was looking at an issue
where someone bumped their head with this "problem", so great that
we're in a better place now. Hopefully one day everyone will be
running PG15 or better :)

Kind regards, Martín

El mié, 6 abr 2022 a las 16:29, Stephen Frost (<sfrost@snowman.net>) escribió:
>
> Greetings,
>
> * Laurenz Albe (laurenz.albe@cybertec.at) wrote:
> > On Tue, 2022-04-05 at 13:06 -0700, Nathan Bossart wrote:
> > > On Tue, Apr 05, 2022 at 11:25:36AM -0400, Stephen Frost wrote:
> > > > Please find attached an updated patch + commit message.  Mostly, I just
> > > > went through and did a bit more in terms of updating the documentation
> > > > and improving the comments (there were some places that were still
> > > > worrying about the chance of a 'stray' backup_label file existing, which
> > > > isn't possible any longer), along with some additional testing and
> > > > review.  This is looking pretty good to me, but other thoughts are
> > > > certainly welcome.  Otherwise, I'm hoping to commit this tomorrow.
> > >
> > > LGTM!
> >
> > Cassandra (not the software) from the sidelines predicts that we will
> > get some fire from users for this, although I concede the theoretical
> > sanity of the change.
>
> Great, thanks for that.
>
> This has now been committed- thanks again to everyone for their help!
>
> Stephen



--
Martín Marqués
It’s not that I have something to hide,
it’s that I have nothing I want you to see



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Odd off-by-one dirty buffers and checkpoint buffers written
Next
From: Michael Paquier
Date:
Subject: Re: minor MERGE cleanups