Re: pg_basebackup questions

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: hartrc <rhart2(at)mt(dot)gov>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: pg_basebackup questions
Date: 2012-12-01 13:43:26
Message-ID: CABUevEy3r-K2NfbV25rC9S5NtboC7n+1WST9iN=bAgtePMaOWw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Nov 30, 2012 at 7:28 PM, hartrc <rhart2(at)mt(dot)gov> wrote:
> Hi,
>
> PostgreSQL 9.1.6
> Linux (SLES 11)
>
> i have a pg_basebackup job that is executed within a script.
> My command is:
>
> /postgresql/v91/bin/pg_basebackup -h 127.0.0.1 -D
> /postgresql/pg_backup/backupdir -Ft -Z 5
>
> The result of this creates 2 files: base.tar and 16450.tar
>
> I understand that 16450 is the oid of the additional tablespace i created
> however this tablespace resides within the data directory so as far as i can
> tell (and have tested) suggests this is a duplicate.

Why do you have a separate tablespace within the data directory?!

> I did a test restore and was able to recover all tablespaces from the
> base.tar without any issues - confirming my suspicion that 16450.tar is
> essentially an uneeded duplicate backup.
>
> What pg_basebackup command would i run to avoid created of 16450.tar ?

There is no way to do that. What you should do is move your tablespace
outside the main data directory. If you want the data in the main data
directory, there is no point to creating the tablespace.

> Another thing is that during pg_basebackup i get warning:
> pg_basebackupWARNING: could not read symbolic link
> "pg_tblspc/mytablespacename": Invalid argument
>
> Again based on my successful recovery i'm assuming this is not a major issue
> but it is still a little disconcerting.

This indicates that you have something in pg_tblspc that is not a
symlink. That's never supposed to happen, so your data directory is
"corrupt". It's probably not something that actually causes a problem
other than this one in the backup - for now at least. But the fix is
moving the tablespace to a proper location.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Dmitriy Igrishin 2012-12-01 16:58:52 Re: pg_listening_channels()
Previous Message Pavel Stehule 2012-12-01 12:14:08 Re: proposal: fix corner use case of variadic fuctions usage