Re: refactoring basebackup.c
| От | Jeevan Ladhe |
|---|---|
| Тема | Re: refactoring basebackup.c |
| Дата | |
| Msg-id | CAOgcT0Od8AOuRog4CTzOGmyto7ybMTw9cPL6PG5kzdreXAPAfA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: refactoring basebackup.c (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: refactoring basebackup.c
|
| Список | pgsql-hackers |
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.
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
Regards,
Jeevan Ladhe
On Tue, Sep 21, 2021 at 10:22 PM Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Sep 21, 2021 at 7:54 AM Jeevan Ladhe
<jeevan.ladhe@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
Вложения
В списке pgsql-hackers по дате отправления: