they're explicitly told not to do that and that seems like the
best move. I also don't particularly care about silly "what ifs" like
if someone randomly copies the data directory after the restore- yes,
there's a lot of ways that people can screw things up by doing thi
ugh to detect
cases where we still believe the claim. But there's probably a long
tail of weird ways for whatever you come up with to be deceived.
In the case of the recovery_init_sync_method=wal patch proposed in
*this* thread, here's the thing: there's not much to gain by trying to
s
Greetings,
* Thomas Munro (thomas.mu...@gmail.com) wrote:
> 2. You made a file system-level copy of a cluster that you shut down
> cleanly first, using cp, tar, scp, rsync, xmodem etc. Now you start
> up the copy. Its checkpoint is a forgery. (Maybe our manual should
> mention this problem und
et flushed to disk, and that don't happen to be dirtied (or
skipped with BLK_DONE) by WAL replay.
recovery_init_sync_method=fsync,syncfs will fix at least that second
problem for you.
Now, what holes are there in this scheme?
[1] https://postgr.es/m/11bc2bb7-ecb5-3ad0-b39f-df632734cd81%40di
