On Mon, Mar 05, 2018 at 11:18:20AM +0100, Daniel Gustafsson wrote:
> > On 02 Mar 2018, at 12:59, Greg Stark wrote:
>
> > My feeling is that worrying about in-place binary upgrades today
> > is wasted effort. Already the window for installations where this
> > is useful is narrow -- you have to be
> On 02 Mar 2018, at 01:03, Bruce Momjian wrote:
>
> On Tue, Feb 6, 2018 at 01:51:09PM +0100, Daniel Gustafsson wrote:
>>> On 06 Feb 2018, at 01:09, David Fetter wrote:
>>
>>> - pg_upgrade is very much a blocker for on-disk format changes.
>>
>> I wouldn’t call it a blocker, but pg_upgrade ac
> On 02 Mar 2018, at 12:59, Greg Stark wrote:
> My feeling is that worrying about in-place binary upgrades today is
> wasted effort. Already the window for installations where this is
> useful is narrow -- you have to be big enough that the resources for
> deploying a second instance is significa
On 6 February 2018 at 03:13, Craig Ringer wrote:
> On 6 February 2018 at 09:51, Joshua D. Drake wrote:
>>
>> On 02/05/2018 04:09 PM, David Fetter wrote:
>>
>>> Does this seem worth coding up in its current form?
>>
>> No. The pg_upgrade utility is awesome and I have commended Bruce on
>> multiple
On Tue, Feb 6, 2018 at 01:51:09PM +0100, Daniel Gustafsson wrote:
> > On 06 Feb 2018, at 01:09, David Fetter wrote:
>
> > - pg_upgrade is very much a blocker for on-disk format changes.
>
> I wouldn’t call it a blocker, but pg_upgrade across an on-disk format change
> would be a very different
> On 06 Feb 2018, at 01:09, David Fetter wrote:
> - pg_upgrade is very much a blocker for on-disk format changes.
I wouldn’t call it a blocker, but pg_upgrade across an on-disk format change
would be a very different experience from what we have today since it would
need to read and rewrite data
På tirsdag 06. februar 2018 kl. 01:09:18, skrev David Fetter mailto:da...@fetter.org>>:
Folks,
While chatting with Bruce about how to make something better than
pg_upgrade, we (and by "we," I mean mostly Bruce) came up with the
following.
What needs improvement:
- pg_upgrade forces a down t
On 6 February 2018 at 09:51, Joshua D. Drake wrote:
> On 02/05/2018 04:09 PM, David Fetter wrote:
>
>> Does this seem worth coding up in its current form?
>>
>
> No. The pg_upgrade utility is awesome and I have commended Bruce on
> multiple occasions about his work with it. That being said, the
>
On 02/05/2018 04:09 PM, David Fetter wrote:
Does this seem worth coding up in its current form?
No. The pg_upgrade utility is awesome and I have commended Bruce on
multiple occasions about his work with it. That being said, the
"solution" is to support in-place upgrades and our work should be
On 2/5/18 19:09, David Fetter wrote:
> - Add a new script--possibly Perl or Bash, which would:
> - Initdb a new cluster with the new version of PostgreSQL and a
> different port.
This will need integration with the packaging system. You'll want to
carry over settings from the old instan
On 6 February 2018 at 08:09, David Fetter wrote:
> Folks,
>
> While chatting with Bruce about how to make something better than
> pg_upgrade, we (and by "we," I mean mostly Bruce) came up with the
> following.
>
> What needs improvement:
>
> - pg_upgrade forces a down time event, no matter how cl
On Mon, Feb 5, 2018 at 5:09 PM, David Fetter wrote:
>
> The proposal has blockers:
>
> - We don't actually have logical decoding for DDL, although I'm given
> to understand that Álvaro Herrera has done some yeoman follow-up
> work on Dimitri Fontaine's PoC patches.
> - We don't have logical d
Folks,
While chatting with Bruce about how to make something better than
pg_upgrade, we (and by "we," I mean mostly Bruce) came up with the
following.
What needs improvement:
- pg_upgrade forces a down time event, no matter how cleverly it's done.
- pg_upgrade is very much a blocker for on-disk
13 matches
Mail list logo
