Re: refactoring basebackup.c

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 <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, Sep 21, 2021 at 7:54 AM Jeevan Ladhe
> <jeevan(dot)ladhe(at)enterprisedb(dot)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
>