> >> Let's imagine someone follows your advice but is already running a PITR archive with archive_timeout. The recommended timeout is 1 minute. Every minute their server generates a new WAL segment. > > Yeah, I'm always assuming streaming replication. If you know you have a delay in replication, you'd better remember that ;-) If we agree on that assumption, then: There is definitely a race condition between the generation of WAL by archive_timeout and any SQL-based check that you might do against the server to see it's WAL state before shutting down, which can result in WAL that is not synchronised between master and standby (and which you do not know is not synchronised). And a possible further race condition between the generation of WAL by archive timeout and the shutdown process, depending on at what point in the shutdown process the server ceases to generate new WAL, which can also result in WAL that is not synchronised between master and standby (and which you do not know is not synchronised). "Similar" or "Maybe the same" isn't going to be good enough here for reliable behaviour. Graeme Bell -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
