Re: WAL archive is lost - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: WAL archive is lost
Date
Msg-id CAMkU=1zAeWh7jdFmHw5R9sjJpzq9fKwMxiYp1-m+JOY2Bi1rsg@mail.gmail.com
Whole thread Raw
In response to WAL archive is lost  ("matsumura.ryo@fujitsu.com" <matsumura.ryo@fujitsu.com>)
Responses RE: WAL archive is lost  ("matsumura.ryo@fujitsu.com" <matsumura.ryo@fujitsu.com>)
List pgsql-hackers
On Fri, Nov 22, 2019 at 8:04 AM matsumura.ryo@fujitsu.com <matsumura.ryo@fujitsu.com> wrote:
Hi all

I find a situation that WAL archive file is lost but any WAL segment file is not lost.
It causes for archive recovery to fail. Is this behavior a bug?

example:

  WAL segment files
  000000010000000000000001
  000000010000000000000002
  000000010000000000000003

  Archive files
  000000010000000000000001
  000000010000000000000003

  Archive file 000000010000000000000002 is lost but WAL segment files
  is continuous. Recovery with archive (i.e. PITR) stops at the end of
  000000010000000000000001.

Will it not archive  000000010000000000000002 eventually, like at the conclusion of the next restartpoint?  or does it get recycled/removed without ever being archived?  Or does it just hang out forever in pg_wal?
 


How to reproduce:
- Set up replication (primary and standby).
- Set [archive_mode = always] in standby.
- WAL receiver exits (i.e. because primary goes down)
  after receiver inserts the last record in some WAL segment file
  before receiver notifies the segement file to archiver(create .ready file).

Do you have a trick for reliably achieving this last step?

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: dropdb --force
Next
From: Joe Conway
Date:
Subject: Re: add a MAC check for TRUNCATE