Re: BUG #17684: pg_rewind ---could not receive data from WAL stream: ERROR: requested WAL segment 00000005000000000

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: 1726002692(at)qq(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17684: pg_rewind ---could not receive data from WAL stream: ERROR: requested WAL segment 00000005000000000
Date: 2022-11-14 02:52:56
Message-ID: 20221114.115256.508829456679239510.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

At Fri, 11 Nov 2022 10:51:20 +0000, PG Bug reporting form <noreply(at)postgresql(dot)org> wrote in
> Master:192.168.247.110
> Standby:192.168.247.100
> Faiover On Standby:pg_ctl promote
>
> On the host 192.168.247.110 :
> pg_ctl stop -$PGDATA
> pg_rewind --target-pgdata=$PGDATA --source-server='host=192.168.247.100
> port=5432 user=postgres password=pass dbname=postgres' -R
> pg_ctl start -D $PGDATA
>
> but ,the pg instance not started
> error log:could not receive data from WAL stream: ERROR: requested WAL
> segment 000000050000000000000029 has already been removed

This report does not have enough information, but it seems like
related to [1]. Namely, pg_rewind removes WAL files in the target that
the source server does not have in pg_wal directory even though some
of the files are required at the first startup. That behavior is not a
bug itself (designed behavior) but could be annoying in some use
cases.

If I'm right, [1] would resolve your trouble. For the mement, using
primary's archive at the first startup of the standby would be a work
around.

[1] https://www.postgresql.org/message-id/CAAtGL4CM7hA0G4dS-Z_RckMy%2Bpzz_KGV2b%3D8ivDPTgaU4nySGg%40mail.gmail.com

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2022-11-14 07:20:57 BUG #17687: Session timezone change does not play well with prepared statements
Previous Message Tom Lane 2022-11-13 15:39:09 Re: pg_prepared_statements missing column