Thread
Commits
-
pg_basebackup: Fix cross-platform tablespace relocation.
- ba58266eb8db 10.23 landed
- 38214dabd425 11.18 landed
- 475e9daf3979 12.13 landed
- 0bf2cd1602b1 13.9 landed
- aaad8adb02ed 14.6 landed
- 5c013e620c91 15.1 landed
- 1f0c4fa25525 16.0 landed
-
cross-platform pg_basebackup
Robert Haas <robertmhaas@gmail.com> — 2022-10-20T15:11:17Z
Suppose that, for some reason, you want to use pg_basebackup on a Linux machine to back up a database cluster on a Windows machine. Suppose further that you attempt to use the -T option. Then you might run afoul of this check: /* * This check isn't absolutely necessary. But all tablespaces are created * with absolute directories, so specifying a non-absolute path here would * just never match, possibly confusing users. It's also good to be * consistent with the new_dir check. */ if (!is_absolute_path(cell->old_dir)) pg_fatal("old directory is not an absolute path in tablespace mapping: %s", cell->old_dir); The problem is that the definition of is_absolute_path() here differs depending on whether you are on Windows or not. So this code is, I think, subtly incorrect. What it is testing is whether the user-specified pathname is an absolute pathname *on the local machine* whereas what it should be testing is whether the user-specified pathname is an absolute pathname *on the remote machine*. There's no problem if both sides are Windows or neither side is Windows, but if the remote side is and the local side isn't, then something like -TC:\foo=/backup/foo will fail. As far as I know, there's no reason why that shouldn't be permitted to work. What this check is actually intending to prevent, I believe, is something like -T../mytablespace=/bkp/ts1, because that wouldn't actually work: the value in the list will be an absolute path. The tablespace wouldn't get remapped, and the user might be confused about why it didn't, so it is good that we tell them what they did wrong. However, I think we could relax the check a little bit, something along the lines of !is_nonwindows_absolute_path(cell->old_dir) && !is_windows_absolute_path(dir). We can't actually know whether the remote side is Windows or non-Windows, but if the string we're given is plausibly an absolute path under either set of conventions, it's probably fine to just search the list for it and see if it shows up. This would have the disadvantage that if a Linux user creates a tablespace directory inside $PGDATA and gives it a name like /home/rhaas/pgdata/C:\Program Files\PostgreSQL\Data, and then attempts a backup with '-TC:\Program Files\PostgreSQL\Data=/tmp/ts1' it will not relocate the tablespace, yet the user won't get a message explaining why. I'm prepared to dismiss that scenario as "not a real use case". Thoughts? -- Robert Haas EDB: http://www.enterprisedb.com -
Re: cross-platform pg_basebackup
Tom Lane <tgl@sss.pgh.pa.us> — 2022-10-20T16:17:12Z
Robert Haas <robertmhaas@gmail.com> writes: > However, I think we could relax the check a little bit, something > along the lines of !is_nonwindows_absolute_path(cell->old_dir) && > !is_windows_absolute_path(dir). We can't actually know whether the > remote side is Windows or non-Windows, but if the string we're given > is plausibly an absolute path under either set of conventions, it's > probably fine to just search the list for it and see if it shows up. Seems reasonable. > This would have the disadvantage that if a Linux user creates a > tablespace directory inside $PGDATA and gives it a name like > /home/rhaas/pgdata/C:\Program Files\PostgreSQL\Data, and then attempts > a backup with '-TC:\Program Files\PostgreSQL\Data=/tmp/ts1' it will > not relocate the tablespace, yet the user won't get a message > explaining why. I'm prepared to dismiss that scenario as "not a real > use case". Agreed. regards, tom lane
-
Re: cross-platform pg_basebackup
Robert Haas <robertmhaas@gmail.com> — 2022-10-20T17:04:48Z
On Thu, Oct 20, 2022 at 12:17 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > However, I think we could relax the check a little bit, something > > along the lines of !is_nonwindows_absolute_path(cell->old_dir) && > > !is_windows_absolute_path(dir). We can't actually know whether the > > remote side is Windows or non-Windows, but if the string we're given > > is plausibly an absolute path under either set of conventions, it's > > probably fine to just search the list for it and see if it shows up. > > Seems reasonable. Cool. Here's a patch. -- Robert Haas EDB: http://www.enterprisedb.com
-
Re: cross-platform pg_basebackup
Tom Lane <tgl@sss.pgh.pa.us> — 2022-10-20T17:28:06Z
Robert Haas <robertmhaas@gmail.com> writes: > Cool. Here's a patch. LGTM, except I'd be inclined to ensure that all the macros are function-style, ie +#define IS_DIR_SEP(ch) IS_NONWINDOWS_DIR_SEP(ch) not just +#define IS_DIR_SEP IS_NONWINDOWS_DIR_SEP I don't recall the exact rules, but I know that the second style can lead to expanding the macro in more cases, which we likely don't want. It also seems like better documentation to show the expected arguments. regards, tom lane
-
Re: cross-platform pg_basebackup
Robert Haas <robertmhaas@gmail.com> — 2022-10-20T18:47:21Z
On Thu, Oct 20, 2022 at 1:28 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > Cool. Here's a patch. > > LGTM, except I'd be inclined to ensure that all the macros > are function-style, ie > > +#define IS_DIR_SEP(ch) IS_NONWINDOWS_DIR_SEP(ch) > > not just > > +#define IS_DIR_SEP IS_NONWINDOWS_DIR_SEP > > I don't recall the exact rules, but I know that the second style > can lead to expanding the macro in more cases, which we likely > don't want. It also seems like better documentation to show > the expected arguments. OK, thanks. v2 attached. -- Robert Haas EDB: http://www.enterprisedb.com
-
Re: cross-platform pg_basebackup
Andrew Dunstan <andrew@dunslane.net> — 2022-10-20T19:12:12Z
On 2022-10-20 Th 14:47, Robert Haas wrote: > On Thu, Oct 20, 2022 at 1:28 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> Cool. Here's a patch. >> LGTM, except I'd be inclined to ensure that all the macros >> are function-style, ie >> >> +#define IS_DIR_SEP(ch) IS_NONWINDOWS_DIR_SEP(ch) >> >> not just >> >> +#define IS_DIR_SEP IS_NONWINDOWS_DIR_SEP >> >> I don't recall the exact rules, but I know that the second style >> can lead to expanding the macro in more cases, which we likely >> don't want. It also seems like better documentation to show >> the expected arguments. > OK, thanks. v2 attached. > Looks good. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
-
Re: cross-platform pg_basebackup
davinder singh <davindersingh2692@gmail.com> — 2022-10-21T08:14:33Z
Hi, Patch v2 looks good to me, I have tested it, and pg_basebackup works fine across the platforms (Windows to Linux and Linux to Windows). Syntax used for testing $ pg_basebackup -h remote_server_ip -p 5432 -U user_name -D backup/data -T olddir=newdir I have also tested with non-absolute paths, it behaves as expected. On Fri, Oct 21, 2022 at 12:42 AM Andrew Dunstan <andrew@dunslane.net> wrote: > > On 2022-10-20 Th 14:47, Robert Haas wrote: > > On Thu, Oct 20, 2022 at 1:28 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Robert Haas <robertmhaas@gmail.com> writes: > >>> Cool. Here's a patch. > >> LGTM, except I'd be inclined to ensure that all the macros > >> are function-style, ie > >> > >> +#define IS_DIR_SEP(ch) IS_NONWINDOWS_DIR_SEP(ch) > >> > >> not just > >> > >> +#define IS_DIR_SEP IS_NONWINDOWS_DIR_SEP > >> > >> I don't recall the exact rules, but I know that the second style > >> can lead to expanding the macro in more cases, which we likely > >> don't want. It also seems like better documentation to show > >> the expected arguments. > > OK, thanks. v2 attached. > > > > > Looks good. > > > cheers > > > andrew > > -- > Andrew Dunstan > EDB: https://www.enterprisedb.com > > > > -- Regards, Davinder EnterpriseDB: http://www.enterprisedb.com
-
Re: cross-platform pg_basebackup
Robert Haas <robertmhaas@gmail.com> — 2022-10-21T13:15:39Z
On Fri, Oct 21, 2022 at 4:14 AM davinder singh <davindersingh2692@gmail.com> wrote: > Hi, > Patch v2 looks good to me, I have tested it, and pg_basebackup works fine across the platforms (Windows to Linux and Linux to Windows). > Syntax used for testing > $ pg_basebackup -h remote_server_ip -p 5432 -U user_name -D backup/data -T olddir=newdir > > I have also tested with non-absolute paths, it behaves as expected. Cool. Thanks to you, Andrew, and Tom for reviewing. Committed and back-patched to all supported branches. -- Robert Haas EDB: http://www.enterprisedb.com
-
Re: cross-platform pg_basebackup
Julien Rouhaud <rjuju123@gmail.com> — 2022-10-24T02:44:26Z
Hi, On Fri, Oct 21, 2022 at 09:15:39AM -0400, Robert Haas wrote: > > Committed and back-patched to all supported branches. Is there any additional things to be taken care of or should https://commitfest.postgresql.org/40/3954/ be closed?
-
Re: cross-platform pg_basebackup
Robert Haas <robertmhaas@gmail.com> — 2022-10-28T16:07:13Z
On Sun, Oct 23, 2022 at 10:44 PM Julien Rouhaud <rjuju123@gmail.com> wrote: > On Fri, Oct 21, 2022 at 09:15:39AM -0400, Robert Haas wrote: > > Committed and back-patched to all supported branches. > > Is there any additional things to be taken care of or should > https://commitfest.postgresql.org/40/3954/ be closed? As far as I know we're done. I have closed that entry. -- Robert Haas EDB: http://www.enterprisedb.com