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
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 |