| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Dennis Jacobfeuerborn <dennisml(at)conversis(dot)de> |
| Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: "invalid record length" after restoring pg_basebackup |
| Date: | 2020-11-16 15:03:41 |
| Message-ID: | 756951.1605539021@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Dennis Jacobfeuerborn <dennisml(at)conversis(dot)de> writes:
> On 11/13/20 4:02 PM, Tom Lane wrote:
>> This looks quite normal to me. If you'd pulled the power plug on the
>> primary system at the time you made this backup, you would likely see
>> the same message at the end of its crash recovery. Some sort of
>> corrupt-WAL-entry report is expected at the end of WAL replay anytime
>> you didn't have a clean shutdown.
> But the system the backup was pulled from kept running fine. Also
> wouldn't that make re-attaching the system to the primary impossible
> since replication cannot be continued due to the broken WAL record?
There is no "broken WAL record". There is only junk following the
primary's current WAL write point.
> What I would expect is that pg_basebackup only transfer healthy WAL
> entries so that a restored system can pick up right after that with
> streaming replication.
You need to adjust your expectations. pg_basebackup doesn't parse the WAL
data, because it has no need to. It just copies whole WAL segment files.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2020-11-16 17:14:06 | Re: Unable to compile postgres 13.1 on Slackware current x64 |
| Previous Message | Condor | 2020-11-16 14:12:18 | Re: Unable to compile postgres 13.1 on Slackware current x64 |