On 4/19/24 01:10, Robert Haas wrote:
On Wed, Apr 17, 2024 at 7:56 PM David Steele wrote:
Thanks! I've tested this and it works as advertised.
Ideally I'd want an error on backup if there is a similar file in any
data directories that would cause an error on combine, but I admit that
it is vani
On Wed, Apr 17, 2024 at 7:56 PM David Steele wrote:
> Thanks! I've tested this and it works as advertised.
>
> Ideally I'd want an error on backup if there is a similar file in any
> data directories that would cause an error on combine, but I admit that
> it is vanishingly rare for users to put f
On 4/18/24 00:14, Robert Haas wrote:
On Tue, Apr 16, 2024 at 9:25 AM Robert Haas wrote:
On Mon, Apr 15, 2024 at 10:12 PM David Steele wrote:
Anyway, I think it should be fixed or documented as a caveat since it
causes a hard failure on restore.
Alright, I'll look into this.
Here's a patch
On Tue, Apr 16, 2024 at 9:25 AM Robert Haas wrote:
> On Mon, Apr 15, 2024 at 10:12 PM David Steele wrote:
> > Anyway, I think it should be fixed or documented as a caveat since it
> > causes a hard failure on restore.
>
> Alright, I'll look into this.
Here's a patch.
--
Robert Haas
EDB: http:/
On Tue, Apr 16, 2024 at 12:06 PM Stefan Fercot
wrote:
> Sure, I can see your point here and how people could be tempted to through
> away that backup_manifest if they don't know how important it is to keep it.
> Probably in this case we'd need the list to be inside the tar, just like
> backup_la
On Tuesday, April 16th, 2024 at 3:22 PM, Robert Haas wrote:
> What I fear is that this will turn into another situation like we had
> with pg_xlog, where people saw "log" in the name and just blew it
> away. Matter of fact, I recently encountered one of my few recent
> examples of someone doing tha
On Mon, Apr 15, 2024 at 10:12 PM David Steele wrote:
> Anyway, I think it should be fixed or documented as a caveat since it
> causes a hard failure on restore.
Alright, I'll look into this.
> I know Tomas added some optimizations that work best with --no-manifest
> but if we can eventually read
On Tue, Apr 16, 2024 at 3:10 AM Stefan Fercot
wrote:
> > > But ... I didn't really end up feeling very comfortable with it. Right
> > > now, the backup manifest is something we only use to verify the
> > > integrity of the backup. If we were to do this, it would become a
> > > critical part of the
Hi,
> I think it would be reasonable to restrict what can be put in base/ and
> global/ but users generally feel free to create whatever they want in
> the root of PGDATA, despite being strongly encouraged not to.
>
> Anyway, I think it should be fixed or documented as a caveat since it
> causes
On 4/16/24 06:33, Robert Haas wrote:
On Sun, Apr 14, 2024 at 11:53 PM David Steele wrote:
Since incremental backup is using INCREMENTAL as a keyword (rather than
storing incremental info in the manifest) it is vulnerable to any file
in PGDATA with the pattern INCREMENTAL.*.
Yeah, that's true.
On Sun, Apr 14, 2024 at 11:53 PM David Steele wrote:
> Since incremental backup is using INCREMENTAL as a keyword (rather than
> storing incremental info in the manifest) it is vulnerable to any file
> in PGDATA with the pattern INCREMENTAL.*.
Yeah, that's true. I'm not greatly concerned about th
Hackers,
Since incremental backup is using INCREMENTAL as a keyword (rather than
storing incremental info in the manifest) it is vulnerable to any file
in PGDATA with the pattern INCREMENTAL.*.
For example:
$ pg_basebackup -c fast -D test/backup/full -F plain
$ touch test/data/INCREMENTAL.CO
12 matches
Mail list logo
