Re: pg_basebackup bug: base backup is double the size of the database

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Wed, Jan 21, 2015 at 3:32 PM, Craig James <cjames@xxxxxxxxxxxxxx> wrote:
# ls -l /data/postgres-9.3/main/pg_tblspc/16747
lrwxrwxrwx 1 postgres postgres 27 2014-08-18 11:28 /data/postgres-9.3/main/pg_tblspc/16747 -> /postgres/tablespaces/uorsy/

# du -sh /data/postgres-9.3/tablespaces/uorsy
35G     /data/postgres-9.3/tablespaces/uorsy

# du -sh /data/postgres-9.3/tablespaces/uorsy/*
35G     /data/postgres-9.3/tablespaces/uorsy/8208624
8.1M    /data/postgres-9.3/tablespaces/uorsy/PG_9.3_201306121
4.0K    /data/postgres-9.3/tablespaces/uorsy/pgsql_tmp
4.0K    /data/postgres-9.3/tablespaces/uorsy/PG_VERSION

# find /data/postgres-9.3/tablespaces/uorsy \! -links 1 -type f | wc -l
740


Am I overlooking or is there something really wrong here?

First, all files of a tablespace should be inside PG_9.3_201306121 directory, why do you have those other files? Second, there shouldn't be any hard link inside of a tablespace, as PostgreSQL is not creating them, someone must have done it by hand. I'm guessing all inside PG_9.3_201306121 is linked to the root path of the tablespace, which is wrong.

If I'm not overlooking, then neither barman nor pg_basebackup is to blame, but whoever created the hard links; if PostgreSQL did this (which I doubt) then it is a bug.

Regards,
--
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux