Re: Broken hint bits (freeze)

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Sergey Burladyan <eshkinkot(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Dmitriy Sarafannikov <dsarafannikov(at)yandex(dot)ru>, Vladimir Borodin <root(at)simply(dot)name>
Subject: Re: Broken hint bits (freeze)
Date: 2017-07-03 04:39:43
Message-ID: CAA4eK1LQT5LQcGB5Hq+e4Vfb2bc5MCM6_WBbi9arecuAB-6m7g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 29, 2017 at 6:57 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Sat, Jun 24, 2017 at 09:24:21AM +0530, Amit Kapila wrote:
>> > I was not clear. I was not saying there can be only one extra WAL file.
>> > I am saying the "Latest checkpoint location" should be one WAL file
>> > farther on the master. I think the big problem is that we need a full
>> > replay of that WAL file, not just having it one less than the master.
>> >
>>
>> If the user has properly shutdown, then that last file should only
>> have checkpoint record, is it safe to proceed with upgrade without
>> actually copying that file?
>
> Yes, but how do we know they processed all the records in the
> second-to-last WAL file (in WAL shipping mode).
>

I don't see any straightforward way to know the same except that user
gets the latest WAL location (replay or flush) and then verify it
against last wal file (maybe by using something like pg_waldump). I
think the another problem as pointed by Sergey up thread is how to
ensure all the buffers that contain changes are flushed to disk.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2017-07-03 05:00:11 Re: Multi column range partition table
Previous Message Amit Kapila 2017-07-03 03:42:01 hash index on unlogged tables doesn't behave as expected