Re: option -T in pg_basebackup doesn't work on windows
От | Heikki Linnakangas |
---|---|
Тема | Re: option -T in pg_basebackup doesn't work on windows |
Дата | |
Msg-id | 53F6F1AA.2090905@vmware.com обсуждение исходный текст |
Ответ на | Re: option -T in pg_basebackup doesn't work on windows (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: option -T in pg_basebackup doesn't work on windows
|
Список | pgsql-hackers |
On 08/22/2014 07:08 AM, Amit Kapila wrote: > On Thu, Aug 21, 2014 at 3:44 PM, Amit Kapila <amit.kapila16@gmail.com> > wrote: >> >> On Tue, Aug 19, 2014 at 9:51 AM, Amit Kapila <amit.kapila16@gmail.com> > wrote: >>> On Mon, Aug 18, 2014 at 7:50 PM, Heikki Linnakangas < > hlinnakangas@vmware.com> wrote: >>>> Wouldn't it make a lot more sense to create it correctly in the first > place? >>> >>> Looking at the code, I think it is very well possible to create >>> it correctly in the first place without much extra work. I will >>> send a patch if nobody sees any problem with this change. >> >> Attached patch implements the above suggested fix. >> I have removed the earlier code which was used to update the >> symlink path. > > Today morning, I realised that there is one problem with the > patch I sent yesterday and the problem is that incase user > has not given -T option, it will not be able to create the symlink > for appropriate path. Attached patch fix this issue. Thanks, committed with minor changes: * fixed the error message to print the mapped path that it actually tried to create, instead of the original. * there's no need to copy the mapped path string, so I just used a pointer * made the code to do the basetablespace mapping in top of the function a little bit tidier (IMHO anyway), although it wasn't really this patch's. * I noticed that the mappings now apply to any symlinks in the data directory. I think that's OK, we don't expect there to be any other symlinks, especially not pointing to a tablespace location, but if there are, it's arguably a good thing that they are mapped too. - Heikki
В списке pgsql-hackers по дате отправления: