Re: Freeze avoidance of very large table. - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Freeze avoidance of very large table.
Date
Msg-id CA+TgmoYvpsFjDvTmbKT=mSS0UA+ZtjmaKtBPBOh8pLxJm-Y5ig@mail.gmail.com
Whole thread Raw
In response to Re: Freeze avoidance of very large table.  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Freeze avoidance of very large table.
Re: Freeze avoidance of very large table.
List pgsql-hackers
On Mon, Nov 30, 2015 at 12:58 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Mon, Nov 30, 2015 at 10:48:04PM +0530, Masahiko Sawada wrote:
>> On Sun, Nov 29, 2015 at 2:21 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
>> > On Tue, Nov 24, 2015 at 3:13 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>> >>
>> >> Yeah, we need to consider to compute checksum if enabled.
>> >> I've changed the patch, and attached.
>> >> Please review it.
>> >
>> > Thanks for the update.  This now conflicts with the updates doesn to
>> > fix pg_upgrade out-of-space issue on Windows. I've fixed (I think) the
>> > conflict in order to do some testing, but I'd like to get an updated
>> > patch from the author in case I did it wrong.  I don't want to find
>> > bugs that I just introduced myself.
>> >
>>
>> Thank you for having a look.
>
> I would not bother mentioning this detail in the pg_upgrade manual page:
>
> +   Since the format of visibility map has been changed in version 9.6,
> +   <application>pg_upgrade</> creates and rewrite new <literal>'_vm'</literal>
> +   file even if upgrading from 9.5 or before to 9.6 or later with link mode (-k).

Really?  I know we don't always document things like this, but it
seems like a good idea to me that we do so.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Making tab-complete.c easier to maintain
Next
From: Robert Haas
Date:
Subject: Re: Unicode collations in FreeBSD 11, DragonFly BSD 4.4 without ICU