Re: pg_basebackup vs. Windows and tablespaces

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Dilip kumar <dilip(dot)kumar(at)huawei(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_basebackup vs. Windows and tablespaces
Date: 2014-12-20 10:59:35
Message-ID: CAA4eK1Kcx-YfKXHP4x4O9tNZeDaV7iHgdNhgMY+8TCbrne87CQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 17, 2014 at 11:32 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:
> On Tue, Dec 16, 2014 at 10:11 PM, Heikki Linnakangas <
hlinnakangas(at)vmware(dot)com> wrote:
> >
> > On 12/16/2014 06:30 PM, Andrew Dunstan wrote:
> >>
> >> I'm not clear why human readability is the major criterion here. As for
> >> that, it will be quite difficult for a human to distinguish a name with
> >> a space at the end from one without. I really think a simple encoding
> >> scheme would be much the best.
>
> Yeah that could work, but we need the special encoding mainly for newline,
> other's would work with current patch. However it might be worth to do
> it for all kind of spaces. Currently it just reads the line upto newline
using
> fscanf, but if we use special encoding, we might need to read the file
> character by character and check for newline without backslash(or other
> special encoding character); do you have something like that in mind?
>
> Another thing is that we need to take care that we encode/decode link
> path for tar format, as plain format might already be working.
>

Attached patch handles the newline and other characters that are allowed
in tablespace path, as we need escape character only for newline, I have
added the same only for newline. So after patch, the tablespace_map
file will look like below for different kind of paths, as you can see for
tablespace id 16393 which contains newline, there is additional escape
sequence "\" before each newline where as other paths containing space
works as it is.

16391 /home/akapila/mywork/workspace_pg/master/tbs1
16393 /home/akapila/mywork/workspace_pg/master/tbs\
a\
b\

16392 /home/akapila/mywork/workspace_pg/master/tbs 2

So with this, I have handled all review comments raised for this patch
and it is ready for review, as the status of this patch is changed from
"Ready for Committer" to "Waiting on Author", so ideally I think it
should go back to "Ready for Committer", however as I am not very sure
about this point, I will change it to "Needs Review" (correct me if I am
wrong).

Summarization of latest changes:
1. Change file name from symlink_label to tablespace_map and changed
the same every where in comments and variable names.
2. This feature will be supportted for both windows and linux;
tablespace_map
file will be generated on both windows and linux to restore tablespace links
during archive recovery.
3. Handling for special characters in tablesapce path name.
4. Updation of docs.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Attachment Content-Type Size
extend_basebackup_to_include_symlink_v6.patch application/octet-stream 36.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2014-12-20 11:27:05 Re: [HACKERS] Re: Updated libpq5 packages cause connection errors on postgresql 9.2
Previous Message Martijn van Oosterhout 2014-12-20 10:16:47 Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}