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