>Mmm. Maybe something's missing. If you took the base-backup using
>pg_basebackup, that means max_wal_senders > 0 on the primary. If you
>lowered wal_level in the backup (or replica) then started it, You
>would get something like this.
>| FATAL: WAL streaming (max_wal_senders > 0) requires wal_lev
Sorry, I don't known why it showed in wrong format, and try to correct it.
-
When I do PITR in a strange step, I get this FATAL:
2021-01-15 15:02:52.364 CST [14958] FATAL: hot standby is not possible because
wal_level was not set to "replica" or higher on the primary server
2021-01-15 15:0
>> Thanks for your comments.
>>
>> You're understanding is almost the same as mine.
>> It describes when not only backends but also other backgrounds initialize a
>> new wal page,
>> wal buffer's space is already used and there is no space.
>>
>>> 'Total number of times WAL data written to the di
>Now, pg_stat_wal supports reset all informantion in WalStats
>using pg_stat_reset_shared('wal') function.
>Isn't it enough?
Yes it ok, sorry I miss this infomation.
>> 3. I do not think it's a correct describe in document for
>> 'wal_buffers_full'.
>Where should I rewrite the description? If
I think it's really a more convenient way to collect wal usage information,
with it we can query when I want. Several points on my side:
1. It will be nice If you provide a chance to reset the information in WalStats,
so that we can reset it without restart the database.
2. I think 'wal_write_ba
Hello
I read the code and test the patch, it run well on my side, and I have several
issues on the
patch.
1. When call RequestXLogStreaming() during replay, you pick timeline straightly
from control
file, do you think it should pick timeline from timeline history file?
2. In archive recovery m
