Hi Robert, I think the patch v6-0007-Support-base-backup-targets.patch has broken the case for multiple tablespaces. When I tried to take the backup for target 'none' and extract the base.tar I was not able to locate tablespace_map file.
I debugged and figured out in normal tar backup i.e. '-Ft' case pg_basebackup command is sent with TABLESPACE_MAP to the server: BASE_BACKUP ( LABEL 'pg_basebackup base backup', PROGRESS, TABLESPACE_MAP, MANIFEST 'yes', TARGET 'client') But, with the target command i.e. "pg_basebackup -t server:/tmp/data_v1 -Xnone", we are not sending the TABLESPACE_MAP, here is how the command is sent: BASE_BACKUP ( LABEL 'pg_basebackup base backup', PROGRESS, MANIFEST 'yes', TARGET 'server', TARGET_DETAIL '/tmp/data_none') I am attaching a patch to fix this issue. With the patch the command sent is now: BASE_BACKUP ( LABEL 'pg_basebackup base backup', PROGRESS, MANIFEST 'yes', TABLESPACE_MAP, TARGET 'server', TARGET_DETAIL '/tmp/data_none') Regards, Jeevan Ladhe On Tue, Sep 21, 2021 at 10:22 PM Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Sep 21, 2021 at 7:54 AM Jeevan Ladhe > <jeevan.la...@enterprisedb.com> wrote: > > I was wondering if we should change the bbs_buffer_length in bbsink to > > be size_t instead of int, because that's what most of the compression > > libraries have their length variables defined as. > > I looked into this and found that I was already using size_t or Size > in a bunch of related places, so this seems to make sense. > > Here's a new patch set, responding also to Sergei's comments. > > -- > Robert Haas > EDB: http://www.enterprisedb.com >
fix_missing_tablespace_map_issue.patch
Description: Binary data
