Просто отключите кеширование данных запросов
если бы postgresql понял, что кэш устарел, он запросил бы их заново из таблицы
все таки проблема в javascript коде
<input name=user required>
<div class=doom data-plusw=my name>
<div class="doom" data-plusw="my name">
'<div class="doom" data-plusw="' . htmlspecialchars($author['user']) . '">'
Partition #1 contains a linux_raid_member signature.
2019-04-13 15:22:54 - такого времени ещё нет, это же EST, сейчас там 12 только наступило
2019-04-13 15:22:54.761 UTC [2770] LOG: started streaming WAL from primary at 1BCA/DA000000 on timeline 1
2019-04-13 15:22:54.761 UTC [2770] DEBUG: sending write 1BCA/D9FFFFB0 flush 1BCA/D9FFFFB0 apply 1BCA/D9FFFFB0
2019-04-13 15:22:54.761 UTC [2770] DEBUG: sending hot standby feedback xmin 0 epoch 0
2019-04-13 15:22:54.762 UTC [2770] DEBUG: sendtime 2019-04-13 15:22:54.765466+00 receipttime 2019-04-13 15:22:54.762726+00 replication apply delay (N/A) transfer latency 0 ms
2019-04-13 15:22:54.762 UTC [2770] DEBUG: sending write 1BCA/DA020000 flush 1BCA/D9FFFFB0 apply 1BCA/D9FFFFB0
2019-04-13 15:22:54.815 UTC [2770] DEBUG: sending write 1BCA/DA020000 flush 1BCA/DA020000 apply 1BCA/D9FFFFB0
2019-04-13 15:22:54.816 UTC [2770] FATAL: terminating walreceiver process due to administrator command
2019-04-13 10:47:38.334 EST [10121] postgres@[unknown] ERROR: 58P01: requested WAL segment 0000000100001B93000000B7 has already been removed
а явно как указать? тут же не путь до файла вроде.....1BCA/DA000000
2. потому что -Z задаёт уровень компрессии для -z. Который, как я уже писал, делает только сам pg_basebackup. Если его снимать по сети - то это не изменит объём пересылаемых данных.