From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: heap metapages |
Date: | 2012-05-25 11:31:52 |
Message-ID: | CA+U5nMJ5FnR2N5Sa63aszC79PSCugT+0wq0H2SX_hzahqCb19Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 24 May 2012 23:02, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Tue, May 22, 2012 at 09:52:30AM +0100, Simon Riggs wrote:
>> Having pg_upgrade touch data files is both dangerous and difficult to
>> back out in case of mistake, so I am wary of putting the metapage at
>> block 0. Doing it the way I suggest means the .meta files would be
>> wholly new and can be deleted as a back-out. We can also clean away
>> any unnecessary .vm/.fsm files as a later step.
>
> Pg_upgrade never modifies the old cluster, except to lock it in link
> mode, so there is never anything to back out.
Agreed. Robert's proposal was to make pg_upgrade modify the cluster,
which I was observing wasn't a good plan.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2012-05-25 13:06:47 | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile |
Previous Message | Harshitha S | 2012-05-25 10:47:05 | proclock table corrupted |