From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_basebackup for streaming base backups |
Date: | 2011-01-16 17:53:52 |
Message-ID: | m2mxn0d9an.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Sun, Jan 16, 2011 at 18:18, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> No. Don't even think of going there --- we got rid of user-accessible
>> names in the filesystem years ago and we're not going back. Consider
>> CREATE TABLESPACE "/foo/bar" LOCATION '/foo/bar';
>
> Well, we'd try to name the file for that "<oid>-/foo/bar.tar", which I
> guess would break badly, yes.
>
> I guess we could normalize the tablespace name into [a-zA-Z0-9] or so,
> which would still be useful for the majority of cases, I think?
Well if we're not using user names, there's no good choice except for
system name, and the one you're making up here isn't the "true" one…
Now I think the unfriendliness is around the fact that you need to
prepare (untar, unzip) and start a cluster from the backup to be able to
know what file contains what. Is it possible to offer a tool that lists
the logical objects contained into each tar file?
Maybe adding a special section at the beginning of each. That would be
logically like pg_dump "catalog", but implemented as a simple "noise"
file that you simply `cat` with some command.
Once more, I'm still unclear how important that is, but it's scratching.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-01-16 17:59:35 | Re: pg_basebackup for streaming base backups |
Previous Message | Pavel Stehule | 2011-01-16 17:49:27 | Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql |