From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | James Sewell <james(dot)sewell(at)jirotech(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Critical failure of standby |
Date: | 2016-08-20 19:12:30 |
Message-ID: | CAMkU=1y0Le5QpZUq8A-Xh-sc5kLYoSZfFWz8aX-KVn3C0DEBCA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Aug 15, 2016 at 7:23 PM, James Sewell <james(dot)sewell(at)jirotech(dot)com>
wrote:
> Those are all good questions.
>
> Essentially this is a situation where DR is network separated from Prod -
> so I would expect the archive command to fail.
>
archive_command or restore_command? I thought it was restore_command.
> I'll have to check the script it must not be passing the error back
> through to PostgreSQL.
>
> This still shouldn't cause database corruption though right? - it's just
> not getting WALs.
>
If the WAL it does have is corrupt, and it can't replace that with a good
copy because the command is failing, then what else is it going to do?
If the original WAL transfer got interrupted mid-stream, then you will have
a bad record in the middle of the WAL. If by some spectacular stroke of
bad luck, the CRC checksum on that bad record happens to collide, then it
will try to decode that bad record.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | rob stone | 2016-08-20 22:12:23 | Re: endash not a graphic character? |
Previous Message | Bruno Wolff III | 2016-08-20 19:04:05 | endash not a graphic character? |