From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | robertmhaas(at)gmail(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: allow_in_place_tablespaces vs. pg_basebackup |
Date: | 2023-03-09 01:58:41 |
Message-ID: | 20230309.105841.519300390838458436.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Wed, 8 Mar 2023 16:30:05 -0500, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in
> Commit 7170f2159fb21b62c263acd458d781e2f3c3f8bb, which introduced
> in-place tablespaces, didn't make any adjustments to pg_basebackup.
> The resulting behavior is pretty bizarre.
>
> If you take a plain-format backup using pg_basebackup -Fp, then the
> files in the in-place tablespace are backed up, but if you take a
> tar-format backup using pg_basebackup -Ft, then they aren't.
>
> I had at first wondered how this could even be possible, since after
> all a plain format backup is little more than a tar-format backup that
> pg_basebackup chooses to extract for you. The answer turns out to be
> that a tar-format backup activates the server's TABLESPACE_MAP option,
> and a plain-format backup doesn't, and so pg_basebackup can handle
> this case differently depending on the value of that flag, and does.
> Even for a plain-format backup, the server's behavior is not really
> correct, because I think what's happening is that the tablespace files
> are getting included in the base.tar file generated by the server,
> rather than in a separate ${TSOID}.tar file as would normally happen
> for a user-defined tablespace, but because the tar files get extracted
> before the user lays eyes on them, the user-visible consequences are
> masked, at least in the cases I've tested so far.
In my understading, in-place tablespaces are a feature for testing
purpose only. Therefore, the feature was intentionally designed to
have minimal impact on the code and to provide minimum-necessary
behavior for that purpose. I believe it is reasonable to make
basebackup error-out when it encounters an in-place tablespace
directory when TABLESPACE_MAP is activated.
> I'm not sure how messy it's going to be to clean this up. I think each
> tablespace really needs to go into a separate ${TSOID}.tar file,
> because we've got tons of code both on the server side and in
> pg_basebackup that assumes that's how things work, and having in-place
> tablespaces be a rare exception to that rule seems really unappealing.
> This of course also implies that files in an in-place tablespace must
> not go missing from the backup altogether.
The doc clearly describes the purpose of in-place tablespaces and the
potential confusion they can cause for backup tools not excluding
pg_basebackup. Does this not provide sufficient information?
https://www.postgresql.org/docs/devel/runtime-config-developer.html
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-03-09 01:59:13 | Re: meson vs make: missing/inconsistent ENV |
Previous Message | Melanie Plageman | 2023-03-09 01:28:03 | Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode |