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.
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.
--
Robert Haas
EDB: http://www.enterprisedb.com