Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-02-22 Thread Peter Eisentraut
On 2/15/14, 7:05 PM, Peter Eisentraut wrote: I've been working on your patch. Attached is a version I'd be happy to commit. Please check that it's okay with you. Committed after some rebasing. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-02-15 Thread Peter Eisentraut
I've been working on your patch. Attached is a version I'd be happy to commit. Please check that it's okay with you. I rewrote the option argument parsing logic a little bit to be more clear and provide more specific error messages. I reinstated the requirement that both old and new directory

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-02-07 Thread Peter Eisentraut
On 1/29/14, 12:07 PM, Steeve Lennmark wrote: We need to think about how to handle this on platforms without symlinks. I don't like just printing an error message and moving on. It should be either pass or fail or an option to choose between them.

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-01-29 Thread Steeve Lennmark
New patch attached with the following changes: On Thu, Jan 23, 2014 at 11:01 AM, Steeve Lennmark stee...@handeldsbanken.se wrote: On Thu, Jan 23, 2014 at 2:06 AM, Peter Eisentraut pete...@gmx.net wrote: I'm not totally happy with the choice of : as the mapping separator, because that would

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-01-23 Thread Steeve Lennmark
Peter, On Thu, Jan 23, 2014 at 2:06 AM, Peter Eisentraut pete...@gmx.net wrote: I'm tempted to think it should be mandatory to specify this option in plain mode when tablespaces are present. Otherwise, creating a base backup is liable to create random files all over the place. Obviously,

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-01-22 Thread Peter Eisentraut
My review: Clearly, everyone likes this feature. I'm tempted to think it should be mandatory to specify this option in plain mode when tablespaces are present. Otherwise, creating a base backup is liable to create random files all over the place. Obviously, there would be backward

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-01-16 Thread Alvaro Herrera
Please keep the --help and the options in the SGML table in alphabetical order within their respective sections. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-01-16 Thread Alvaro Herrera
Eyeballing this patch, three thoughts: 1. I wonder whether ilist.c/h should be moved to src/common so that frontend code could use it. 2. I wonder whether ilist.c should gain the ability to have singly-linked lists with a pointer to the tail node for appending to the end. This code would use

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-01-16 Thread Andres Freund
Hi, On 2014-01-16 11:25:59 -0300, Alvaro Herrera wrote: Eyeballing this patch, three thoughts: 1. I wonder whether ilist.c/h should be moved to src/common so that frontend code could use it. Sounds like a good idea. There's some debugging checks that elog, but that should be fixable easily.

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-01-16 Thread Steeve Lennmark
Alvaro, On Thu, Jan 16, 2014 at 3:20 PM, Alvaro Herrera alvhe...@2ndquadrant.comwrote: Please keep the --help and the options in the SGML table in alphabetical order within their respective sections. Ah, I failed to see that there was sub groups and thought the options where not

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-01-16 Thread Steeve Lennmark
Alvaro, On Thu, Jan 16, 2014 at 3:25 PM, Alvaro Herrera alvhe...@2ndquadrant.comwrote: Eyeballing this patch, three thoughts: 1. I wonder whether ilist.c/h should be moved to src/common so that frontend code could use it. That would be nice, I guess lack of helpers is why a lot of stuff is

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-01-16 Thread Peter Eisentraut
You appear to be generating your patches with git diff --no-prefix. Don't do that, leave the a/ and b/ in. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-01-12 Thread Andreas Karlsson
On 01/09/2014 10:10 PM, Steeve Lennmark wrote: That's a much better solution, I attached a patch with the updated code. # SELECT oid, pg_tablespace_location(oid) FROM pg_tablespace; [...] 16388 | /tmp/tblspc1 16389 | /tmp/tblspc2 $ pg_basebackup -Xs -D backup/data -T

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-01-12 Thread Alvaro Herrera
Andreas Karlsson wrote: On 01/09/2014 10:10 PM, Steeve Lennmark wrote: That's a much better solution, I attached a patch with the updated code. Looked at the patch quickly and noticed that it does not support paths containing colons. Is that an acceptable limitation? Well, clearly it won't

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-01-10 Thread Gabriele Bartolini
Hi Steeve, Il 09/01/14 22:38, Steeve Lennmark ha scritto: I'm a barman user myself so that was actually my initial thought. Ah! Very good! If there aren't some kind of hidden internal that I've missed I don't see a way to convert an OID (only have OID and path at this stage) to a tablespace

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-01-10 Thread Magnus Hagander
On Fri, Jan 10, 2014 at 12:25 PM, Gabriele Bartolini gabriele.bartol...@2ndquadrant.it wrote: Hi Steeve, Il 09/01/14 22:38, Steeve Lennmark ha scritto: I'm a barman user myself so that was actually my initial thought. Ah! Very good! If there aren't some kind of hidden internal that I've

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-01-10 Thread Andres Freund
On 2014-01-10 12:27:23 +0100, Magnus Hagander wrote: On Fri, Jan 10, 2014 at 12:25 PM, Gabriele Bartolini gabriele.bartol...@2ndquadrant.it wrote: Hi Steeve, Il 09/01/14 22:38, Steeve Lennmark ha scritto: I'm a barman user myself so that was actually my initial thought. Ah! Very

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-01-09 Thread Andreas Karlsson
On 01/09/2014 06:58 PM, Steeve Lennmark wrote: This patch adds the ability to relocate tablespaces by adding the command line argument --tablespace (-T) which takes a required argument in the format oid:tablespacedir. After all tablespaces are fetched this code updates the symlink to point to

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-01-09 Thread Magnus Hagander
On Thu, Jan 9, 2014 at 6:58 PM, Steeve Lennmark stee...@handeldsbanken.sewrote: Currently pg_basebackup is pretty invasive when using tablespaces, at least using the plain format. This since it requires the tablespace to be written to the same location as on the server beeing backed up. This

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-01-09 Thread Gabriele Bartolini
Hi Steeve, Il 09/01/14 22:10, Steeve Lennmark ha scritto: That's a much better solution, I attached a patch with the updated code. # SELECT oid, pg_tablespace_location(oid) FROM pg_tablespace; [...] 16388 | /tmp/tblspc1 16389 | /tmp/tblspc2 I'd suggest, a similar solution to the one we

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

2014-01-09 Thread Steeve Lennmark
On Thu, Jan 9, 2014 at 10:29 PM, Gabriele Bartolini gabriele.bartol...@2ndquadrant.it wrote: Hi Steeve, Il 09/01/14 22:10, Steeve Lennmark ha scritto: That's a much better solution, I attached a patch with the updated code. # SELECT oid, pg_tablespace_location(oid) FROM pg_tablespace;