Re: [HACKERS] Broken hint bits (freeze) - Mailing list pgsql-hackers

From Sergey Burladyan
Subject Re: [HACKERS] Broken hint bits (freeze)
Date
Msg-id 87h8zb6kbx.fsf@seb.koffice.internal
Whole thread Raw
In response to Re: [HACKERS] Broken hint bits (freeze)  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [HACKERS] Broken hint bits (freeze)
Re: [HACKERS] Broken hint bits (freeze)
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:

> On Mon, Jun 19, 2017 at 10:59:19PM -0400, Bruce Momjian wrote:
> > On Tue, Jun 20, 2017 at 03:50:29AM +0300, Sergey Burladyan wrote:
> > > 20 июн. 2017 г. 1:21 пользователь "Bruce Momjian" <bruce@momjian.us> написал: 
> > >
> > >
> > >     We are saying that Log-Shipping should match "Latest checkpoint
> > >     location", but the WAL for that will not be sent to the standby, so it
> > >     will not match, but that is OK since the only thing in the non-shipped
> > >     WAL file is the checkpoint record.  How should we modify the wording on
> > >     this?
> > >
> > >
> > > I am afraid that without this checkpoint record standby cannot make
> > > restartpoint
> > > and without restartpoint it does not sync shared buffers into disk at
> > > shutdown. 
> >
> > Uh, as I understand it the rsync is going to copy the missing WAL file
> > from the new master to the standby, right, and I think pg_controldata
> > too, so it should be fine.  Have you tested to see if it fails?

It need old WAL files from old version for correct restore heap
files. New WAL files from new version does not have this information.

> The point is that we are checking the "Latest checkpoint location" to
> make sure all the WAL was replayed.   We are never going to start the
> old standby server.  Rsync is going to copy the missing/changed files.

Only if missing/changed files changed in size, because rsync run with
--size-only it does not copy changed files with same size.

I have this test script and without copy_last_wal it make standby broken
in the first few loops, like:
=== run 1, cnt: 700000
=== run 2, cnt: 729450

PS: I think what with big shared_buffers I can make it broken more
quickly, but with big shared_buffers I cannot break it at all, hm...

--
Sergey Burladyan


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: [HACKERS] Missing comment for ResultRelInfo in execnodes.h
Next
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] Regarding Postgres Dynamic Shared Memory (DSA)