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-03 11:49:02 |
Message-ID: | 188742f3-a8d0-20b1-2acb-a038a7d5727b@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 3/3/21 2:03 AM, Michael Paquier wrote:
> On Tue, Mar 02, 2021 at 07:46:21AM -0500, David Steele wrote:
>
>> 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?
>
> Err, what you are doing here is qualified as unorthodox, but isn't
> "unsupported" a better term? That's basically tricking WAL replay
> into doing something it would never have to do for physical backups.
OK, but shouldn't we have a full page write for this page after the
backup starts, rather than the partial we seem to be seeing here? Is
there any condition where the full page write would be skipped
legitimately, or does it point to a problem?
If Postgres is running correctly there is certainly no expectation for
support of this unusual use case, but I do think that this possibly
points to an issue in Postgres, which under normal circumstances would
be very hard to detect.
Put another way, what if this page was torn while being copied during
the backup? Would this WAL record still be doing the right thing in that
case?
Regards,
--
-David
david(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2021-03-03 15:16:01 | BUG #16910: I can't install postgresql |
Previous Message | Neil Chen | 2021-03-03 08:41:49 | Re: BUG #16583: merge join on tables with different DB collation behind postgres_fdw fails |