Re: BUG #16003: pg_basebackup failed with error : directory "xxxxxxx" exists but is not empty

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: PG Bug reporting form <noreply(at)postgresql(dot)org>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, sebastien(dot)ruiz(at)harmonie-mutuelle(dot)fr
Subject: Re: BUG #16003: pg_basebackup failed with error : directory "xxxxxxx" exists but is not empty
Date: 2019-09-12 13:27:02
Message-ID: CABUevExO_OwbCA2pMjL3Kecz9y22XNwthcPELrD_2ZcdAivfWA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Sep 12, 2019 at 4:41 AM PG Bug reporting form <
noreply(at)postgresql(dot)org> wrote:

> The following bug has been logged on the website:
>
> Bug reference: 16003
> Logged by: sebastien ruiz
> Email address: sebastien(dot)ruiz(at)harmonie-mutuelle(dot)fr
> PostgreSQL version: 11.4
> Operating system: Red Hat Enterprise Linux Server release 7.6
> Description:
>
> hello,
> (sorry i'm french)
>
> We have a problem when using pg_basebackup.
> We tried to rebuild a slave (master/slave with streaming replication) using
> pg_basebackup like this :
> (executed on the slave server of course)
> pg_basebackup -D /pgbd/IPMUTB6/admin -P -h PGSMUTB61 -p 5432 -U postgres
> -X stream -v --waldir=/pgxlog/IPMUTB6/wal
>
> But it failed :
> pg_basebackup: initiating base backup, waiting for checkpoint to complete
> pg_basebackup: checkpoint completed
> pg_basebackup: write-ahead log start point: 0/17000028 on timeline 5
> pg_basebackup: directory "/pgbd/IPMUTB6/data/dpaafb1_data" exists but is
> not
> empty
> pg_basebackup: removing data directory "/pgbd/IPMUTB6/admin"
> pg_basebackup: removing WAL directory "/pgxlog/IPMUTB6/wal"
> pg_basebackup: changes to tablespace directories will not be undone
>
> in fact it failed because we have an architecture of tablespace who is not
> compatible with the pg_basebackup tests/controls.
>
> This is how our tablespace architecture looks like :
> postgres=# \db
> List of tablespaces
> Name | Owner | Location
>
> -----------------------+----------+-----------------------------------------------
> aafb1_dpaafb1_data | aafb1 |
> /pgbd/IPMUTB6/data/dpaafb1_data/aafb1_data
> aafb1_dpaafb1_idx | aafb1 |
> /pgbd/IPMUTB6/idx/dpaafb1_idx/aafb1_idx
> dpaafb1_data | postgres | /pgbd/IPMUTB6/data/dpaafb1_data
> dpaafb1_idx | postgres | /pgbd/IPMUTB6/idx/dpaafb1_idx
> dpccmb1_data | postgres | /pgbd/IPMUTB6/data/dpccmb1_data
> dpccmb1_idx | postgres | /pgbd/IPMUTB6/idx/dpccmb1_idx
> dptemb1_data | postgres | /pgbd/IPMUTB6/data/dptemb1_data
> dptemb1_idx | postgres | /pgbd/IPMUTB6/idx/dptemb1_idx
> pg_default | postgres |
> pg_global | postgres |
> tech_dpaafb1_data | tech |
> /pgbd/IPMUTB6/data/dpaafb1_data/tech_data
> tech_dpaafb1_idx | tech | /pgbd/IPMUTB6/idx/dpaafb1_idx/tech_idx
> tech_dpccmb1_data | tech |
> /pgbd/IPMUTB6/data/dpccmb1_data/tech_data
> tech_dpccmb1_idx | tech | /pgbd/IPMUTB6/idx/dpccmb1_idx/tech_idx
> tech_dptemb1_data | tech |
> /pgbd/IPMUTB6/data/dptemb1_data/tech_data
> tech_dptemb1_idx | tech | /pgbd/IPMUTB6/idx/dptemb1_idx/tech_idx
> temp | postgres | /pgtemp/IPMUTB6/tmp
> tempob1_dptemb1_data | tempob1 |
> /pgbd/IPMUTB6/data/dptemb1_data/tempob1_data
> tempob1_dptemb1_idx | tempob1 |
> /pgbd/IPMUTB6/idx/dptemb1_idx/tempob1_idx
> webccmb1_dpccmb1_data | webccmb1 |
> /pgbd/IPMUTB6/data/dpccmb1_data/webccmb1_data
> webccmb1_dpccmb1_idx | webccmb1 |
> /pgbd/IPMUTB6/idx/dpccmb1_idx/webccmb1_idx
>
> In summary, we have tablespace directories into tablespace directories.
>
> exemple :
> /pgbd/IPMUTB6/data/dpaafb1_data/aafb1_data is inside the directory
> /pgbd/IPMUTB6/data/dpaafb1_data
>
> And this point is not compatible with pg_basebackup usage.
>
> My question :
> is it possible to make pg_basebackup compatible with this situation ?
> I'm sure that many entreprise have this kind of architecture.
> We can't use pg_basebackup and it's really too bad for us.
>
>
Why do you have multiple tablespaces if they are in the same place? The
appropriate fix for that is to not do that.

And actually putting new tablespace directories inside other tablespaces is
*definitely* not the way it's supposed to be done.

As a workaround, you might be able to use pg_basebackup with -T to relocate
the tablespaces into a directory that is not in conflict.

//Magnus

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Thomas Kellerer 2019-09-12 14:11:52 Re: Unexpected behavior of jsonb_set() with a `null` value
Previous Message Alvaro Herrera 2019-09-12 12:41:35 Re: BUG #16005: cannot use \d to get description of table