Thread: pg_rewind
Hello list, first message here, so first things first: thank you all for apt.postgresql.org (apt.p.o for short). We've been using and recommending it for a while at Anybox, and that has been tremendously useful. Now to my question: I'd like to evaluate pg_rewind [1] with the idea to maybe use it on our production replica sets. Are there any plans to package and include it in apt.p.o ? If not, and we turn out willing to use it, I'd probably try and package it anyway, and would look for the proper place to contribute that. As of now, pg_rewind is not in contrib/ ; would that be against apt.p.o policy ? Lastly, the FAQ seems to suggest that apt.p.o is actually downstream of Debian unstable ("rebuilt"), but I'm not sure to get it right, especially for stuff that's not part of PostgreSQL releases. Regards, [1] https://github.com/vmware/pg_rewind (has separate branches for 9.3 and 9.4) -- Georges Racinet Anybox SAS, http://anybox.fr Bureau: 09 72 39 50 97 / 09 72 39 13 06 Portable: 06 51 32 07 27 GPG: 0x33AB0A35, sur serveurs publics
Re: Georges Racinet 2015-02-08 <54D7542E.2090503@anybox.fr> > Hello list, > > first message here, so first things first: thank you all for > apt.postgresql.org (apt.p.o for short). We've been using and > recommending it for a while at Anybox, and that has been tremendously > useful. Welcome :) > Now to my question: > > I'd like to evaluate pg_rewind [1] with the idea to maybe use it on our > production replica sets. > Are there any plans to package and include it in apt.p.o ? If not, and > we turn out willing to use it, I'd probably try and package it anyway, > and would look for the proper place to contribute that. There's no plans for that, but if you provide a proper package, we can include it. > As of now, pg_rewind is not in contrib/ ; would that be against apt.p.o > policy ? We have plenty of non-core modules as packages. > Lastly, the FAQ seems to suggest that apt.p.o is actually downstream of > Debian unstable ("rebuilt"), but I'm not sure to get it right, > especially for stuff that's not part of PostgreSQL releases. That means that the packages on apt.postgresql.org should preferably be in unstable as well, but that's not a hard requirement. You'll have to argue with me if you don't want that, though ;) > [1] https://github.com/vmware/pg_rewind (has separate branches for 9.3 > and 9.4) Hmm that might be a bit of an issue - the source packages usually support several PG versions in parallel, and then there's individual binary packages built from that. But it's not like that's an unsolvable problem. Christoph -- cb@df7cb.de | http://www.df7cb.de/
Hi, On 02/10/2015 07:40 PM, Christoph Berg wrote: > Re: Georges Racinet 2015-02-08 <54D7542E.2090503@anybox.fr> >> Hello list, >> >> first message here, so first things first: thank you all for >> apt.postgresql.org (apt.p.o for short). We've been using and >> recommending it for a while at Anybox, and that has been tremendously >> useful. > Welcome :) thanks ! >> Now to my question: >> >> I'd like to evaluate pg_rewind [1] with the idea to maybe use it on our >> production replica sets. >> Are there any plans to package and include it in apt.p.o ? If not, and >> we turn out willing to use it, I'd probably try and package it anyway, >> and would look for the proper place to contribute that. > There's no plans for that, but if you provide a proper package, we can > include it. Last week, I couldn't find time to give it a try, but it's still on the todo-list. > >> As of now, pg_rewind is not in contrib/ ; would that be against apt.p.o >> policy ? > We have plenty of non-core modules as packages. > >> Lastly, the FAQ seems to suggest that apt.p.o is actually downstream of >> Debian unstable ("rebuilt"), but I'm not sure to get it right, >> especially for stuff that's not part of PostgreSQL releases. > That means that the packages on apt.postgresql.org should preferably > be in unstable as well, but that's not a hard requirement. You'll have > to argue with me if you don't want that, though ;) I was just wondering about the workflow (which one should come first) and the consequences of Debian's freeze, don't worry :-) > >> [1] https://github.com/vmware/pg_rewind (has separate branches for 9.3 >> and 9.4) > Hmm that might be a bit of an issue - the source packages usually > support several PG versions in parallel, and then there's individual > binary packages built from that. But it's not like that's an > unsolvable problem. I'll make a first try with the 9.4 branch, with explicit PG version pinning. -- Georges Racinet Anybox SAS, http://anybox.fr Bureau: 09 72 39 50 97 / 09 72 39 13 06 Portable: 06 51 32 07 27 GPG: 0x33AB0A35, sur serveurs publics
Re: Georges Racinet 2015-02-16 <54E1BB68.8020308@anybox.fr> > >> Lastly, the FAQ seems to suggest that apt.p.o is actually downstream of > >> Debian unstable ("rebuilt"), but I'm not sure to get it right, > >> especially for stuff that's not part of PostgreSQL releases. > > That means that the packages on apt.postgresql.org should preferably > > be in unstable as well, but that's not a hard requirement. You'll have > > to argue with me if you don't want that, though ;) > I was just wondering about the workflow (which one should come first) > and the consequences of Debian's freeze, don't worry :-) There's also experimental, which works as well. Though for new packages (not present in jessie anyway), uploading to unstable doesn't disturb anything freeze-related. > >> [1] https://github.com/vmware/pg_rewind (has separate branches for 9.3 > >> and 9.4) > > Hmm that might be a bit of an issue - the source packages usually > > support several PG versions in parallel, and then there's individual > > binary packages built from that. But it's not like that's an > > unsolvable problem. > > I'll make a first try with the 9.4 branch, with explicit PG version pinning. Sounds promising :) Christoph -- cb@df7cb.de | http://www.df7cb.de/