Re: BUG #16894: PANIC: WAL contains references to invalid pages

From: David Steele <david(at)pgmasters(dot)net>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Антон Курочкин <antkurochkin(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16894: PANIC: WAL contains references to invalid pages
Date: 2021-03-02 12:46:21
Message-ID: 11b70b37-997e-8a2d-62f3-0f8398b7cafd@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Michael,

On 2/28/21 11:31 PM, Michael Paquier wrote:
> On Thu, Feb 25, 2021 at 12:53:44PM -0500, David Steele wrote:
>> For context, when a user performs selective restore all the relations for
>> databases *not* selected are restored as sparse zero files with the correct
>> size. WAL replay will update those relations but they are not expected to
>> be consistent, and in fact we make it impossible to logon to those databases
>> so the only option is to drop them.
>
> What is a selective restore? Is that a pgbackrest restore mode from a
> full physical backup where only a portion of the database folders are
> physically put back into the data folder restored before doing WAL
> replay up to the consistent point of the full physical backup? Then,
> you emulate the absence of the files from the other database folders
> using files full of zeros but with the same size as the original
> backup to trick WAL replay?

That summarizes the process very well.

My concern here is that we appear to have a partial page write as the
first write to a page after the backup start checkpoint. At least,
that's what this error seems to be indicating from my reading of the code.

The question is -- are there valid circumstances under which this might
be happening or is it a bug?

I have not submitted a bug before this because I am not able to
reproduce it in a test environment, but perhaps somebody can weigh in on
whether this behavior seems normal.

Regards,
--
-David
david(at)pgmasters(dot)net

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michał Albrycht 2021-03-02 14:12:00 Re: BUG #16855: No partition pruning when using partitions with custom hash function
Previous Message PG Bug reporting form 2021-03-02 10:34:55 BUG #16909: On update (not insert) the attisdropped flag is set for tables which are recreated with the same col