2011-01-10 08:03:55 -05:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
|
|
|
|
* basebackup.h
|
|
|
|
|
* Exports from replication/basebackup.c.
|
|
|
|
|
*
|
2023-01-02 15:00:37 -05:00
|
|
|
* Portions Copyright (c) 2010-2023, PostgreSQL Global Development Group
|
2011-01-10 08:03:55 -05:00
|
|
|
*
|
2022-08-10 14:03:23 -04:00
|
|
|
* src/include/backup/basebackup.h
|
2011-01-10 08:03:55 -05:00
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#ifndef _BASEBACKUP_H
|
|
|
|
|
#define _BASEBACKUP_H
|
|
|
|
|
|
2011-08-06 14:53:49 -04:00
|
|
|
#include "nodes/replnodes.h"
|
2011-01-23 17:39:18 -05:00
|
|
|
|
2014-02-27 16:55:57 -05:00
|
|
|
/*
|
|
|
|
|
* Minimum and maximum values of MAX_RATE option in BASE_BACKUP command.
|
|
|
|
|
*/
|
|
|
|
|
#define MAX_RATE_LOWER 32
|
|
|
|
|
#define MAX_RATE_UPPER 1048576
|
|
|
|
|
|
Code review for server's handling of "tablespace map" files.
While looking at Robert Foggia's report, I noticed a passel of
other issues in the same area:
* The scheme for backslash-quoting newlines in pathnames is just
wrong; it will misbehave if the last ordinary character in a pathname
is a backslash. I'm not sure why we're bothering to allow newlines
in tablespace paths, but if we're going to do it we should do it
without introducing other problems. Hence, backslashes themselves
have to be backslashed too.
* The author hadn't read the sscanf man page very carefully, because
this code would drop any leading whitespace from the path. (I doubt
that a tablespace path with leading whitespace could happen in
practice; but if we're bothering to allow newlines in the path, it
sure seems like leading whitespace is little less implausible.) Using
sscanf for the task of finding the first space is overkill anyway.
* While I'm not 100% sure what the rationale for escaping both \r and
\n is, if the idea is to allow Windows newlines in the file then this
code failed, because it'd throw an error if it saw \r followed by \n.
* There's no cross-check for an incomplete final line in the map file,
which would be a likely apparent symptom of the improper-escaping
bug.
On the generation end, aside from the escaping issue we have:
* If needtblspcmapfile is true then do_pg_start_backup will pass back
escaped strings in tablespaceinfo->path values, which no caller wants
or is prepared to deal with. I'm not sure if there's a live bug from
that, but it looks like there might be (given the dubious assumption
that anyone actually has newlines in their tablespace paths).
* It's not being very paranoid about the possibility of random stuff
in the pg_tblspc directory. IMO we should ignore anything without an
OID-like name.
The escaping rule change doesn't seem back-patchable: it'll require
doubling of backslashes in the tablespace_map file, which is basically
a basebackup format change. The odds of that causing trouble are
considerably more than the odds of the existing bug causing trouble.
The rest of this seems somewhat unlikely to cause problems too,
so no back-patch.
2021-03-17 16:18:46 -04:00
|
|
|
/*
|
|
|
|
|
* Information about a tablespace
|
|
|
|
|
*
|
|
|
|
|
* In some usages, "path" can be NULL to denote the PGDATA directory itself.
|
|
|
|
|
*/
|
2015-05-12 09:29:10 -04:00
|
|
|
typedef struct
|
|
|
|
|
{
|
Change struct tablespaceinfo's oid member from 'char *' to 'Oid'
This shouldn't change behavior except in the unusual case where
there are file in the tablespace directory that have entirely
numeric names but are nevertheless not possible names for a
tablespace directory, either because their names have leading zeroes
that shouldn't be there, or the value is actually zero, or because
the value is too large to represent as an OID.
In those cases, the directory would previously have made it into
the list of tablespaceinfo objects and no longer will. Thus, base
backups will now ignore such directories, instead of treating them
as legitimate tablespace directories. Similarly, if entries for
such tablespaces occur in a tablespace_map file, they will now
be rejected as erroneous, instead of being honored.
This is infrastructure for future work that wants to be able to
know the tablespace of each relation that is part of a backup
*as an OID*. By strengthening the up-front validation, we don't
have to worry about weird cases later, and can more easily avoid
repeated string->integer conversions.
Patch by me, reviewed by David Steele.
Discussion: http://postgr.es/m/CA+TgmoZNVeBzoqDL8xvr-nkaepq815jtDR4nJzPew7=3iEuM1g@mail.gmail.com
2023-10-23 15:17:26 -04:00
|
|
|
Oid oid; /* tablespace's OID */
|
Code review for server's handling of "tablespace map" files.
While looking at Robert Foggia's report, I noticed a passel of
other issues in the same area:
* The scheme for backslash-quoting newlines in pathnames is just
wrong; it will misbehave if the last ordinary character in a pathname
is a backslash. I'm not sure why we're bothering to allow newlines
in tablespace paths, but if we're going to do it we should do it
without introducing other problems. Hence, backslashes themselves
have to be backslashed too.
* The author hadn't read the sscanf man page very carefully, because
this code would drop any leading whitespace from the path. (I doubt
that a tablespace path with leading whitespace could happen in
practice; but if we're bothering to allow newlines in the path, it
sure seems like leading whitespace is little less implausible.) Using
sscanf for the task of finding the first space is overkill anyway.
* While I'm not 100% sure what the rationale for escaping both \r and
\n is, if the idea is to allow Windows newlines in the file then this
code failed, because it'd throw an error if it saw \r followed by \n.
* There's no cross-check for an incomplete final line in the map file,
which would be a likely apparent symptom of the improper-escaping
bug.
On the generation end, aside from the escaping issue we have:
* If needtblspcmapfile is true then do_pg_start_backup will pass back
escaped strings in tablespaceinfo->path values, which no caller wants
or is prepared to deal with. I'm not sure if there's a live bug from
that, but it looks like there might be (given the dubious assumption
that anyone actually has newlines in their tablespace paths).
* It's not being very paranoid about the possibility of random stuff
in the pg_tblspc directory. IMO we should ignore anything without an
OID-like name.
The escaping rule change doesn't seem back-patchable: it'll require
doubling of backslashes in the tablespace_map file, which is basically
a basebackup format change. The odds of that causing trouble are
considerably more than the odds of the existing bug causing trouble.
The rest of this seems somewhat unlikely to cause problems too,
so no back-patch.
2021-03-17 16:18:46 -04:00
|
|
|
char *path; /* full path to tablespace's directory */
|
|
|
|
|
char *rpath; /* relative path if it's within PGDATA, else
|
|
|
|
|
* NULL */
|
|
|
|
|
int64 size; /* total size as sent; -1 if not known */
|
2015-05-12 09:29:10 -04:00
|
|
|
} tablespaceinfo;
|
|
|
|
|
|
2011-01-23 17:39:18 -05:00
|
|
|
extern void SendBaseBackup(BaseBackupCmd *cmd);
|
2011-01-10 08:03:55 -05:00
|
|
|
|
|
|
|
|
#endif /* _BASEBACKUP_H */
|
