Re: Broken hint bits (freeze)

From: Vladimir Borodin <root(at)simply(dot)name>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Dmitriy Sarafannikov <dsarafannikov(at)yandex(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Broken hint bits (freeze)
Date: 2017-06-12 15:31:11
Message-ID: C4ADB713-CF88-4A75-A3C3-10E4E0A750DB@simply.name
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> 12 июня 2017 г., в 13:19, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> написал(а):
>
> On Sun, Jun 11, 2017 at 11:59 PM, Vladimir Borodin <root(at)simply(dot)name <mailto:root(at)simply(dot)name>> wrote:
>>
>> 8 июня 2017 г., в 17:03, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> написал(а):
>>
>> On Thu, Jun 8, 2017 at 6:49 PM, Dmitriy Sarafannikov
>> <dsarafannikov(at)yandex(dot)ru> wrote:
>>
>>
>> Why didn't rsync made the copies on master and replica same?
>>
>>
>> Because rsync was running with —size-only flag.
>>
>>
>> IIUC the situation, the new WAL and updated pg_control file has been
>> copied, but not updated data files due to which the WAL has not been
>> replayed on replicas? If so, why the pg_control file is copied, it's
>> size shouldn't have changed?
>>
>>
>> Because on master pg_upgrade moves $prefix/9.5/data/global/pg_control to
>> $prefix/9.5/data/global/pg_control.old and creates new
>> $prefix/9.6/data/global/pg_control without making hardlink. When running
>> rsync from master to replica rsync sees $prefix/9.6/data/global/pg_control
>> on master and checks if it is a hardlink. Since it is not a hardlink and
>> $prefix/9.6/data/global/pg_control does not exist on replica rsync copies
>> it. For data files the logic is different since they are hardlinks,
>> corresponding files exist on replica and they are the same size.
>>
>
> Okay, in that case, I guess it is better to run Analyze on master
> after the upgrade is complete (including an upgrade for replicas). If
> you are worried about the performance of read-only replicas till the
> time Analyze on the master in completed, you might want to use
> --analyze-in-stages of vaccumdb and or use (-j njobs) along with it to
> parallelize the operation.

What about the following sequence?

1. Run pg_upgrade on master,
2. Start it in single-user mode and stop (to get right wal_level in pg_control),
3. Copy pg_control somewhere,
4. Start master, run analyze and stop.
5. Put the control file from step 3 to replicas and rsync them according to the documentation.

And I think that step 10.f in the documentation [1] should be fixed to mention starting in single-user mode or with disabled autovacuum.

[1] https://www.postgresql.org/docs/devel/static/pgupgrade.html

>
>
> --
> With Regards,
> Amit Kapila.
> EnterpriseDB: http://www.enterprisedb.com <http://www.enterprisedb.com/>

--
May the force be with you…
https://simply.name

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-06-12 15:42:52 Re: logical replication NOTICE "synchronized table states"
Previous Message Peter Eisentraut 2017-06-12 15:29:14 Re: pgrowlocks relkind check