I would look at WAL files as a sequence of commits and not a sequence of files within timelines where you can specify either with recovery_target_time or recovery_target_xid the point of consistency you want to reach.
Cheers, A.A. On Fri, Sep 6, 2013 at 1:26 PM, John Lumby <johnlu...@hotmail.com> wrote: > We use logshipping replication, and have recently noticed a nasty bug > where, in certain very rare cases, the primary archive_command program > will fail to send the WAL file to the standby but report good return code > 0 to postgresql. > In such cases, if the standby then triggers its termination of recovery > mode, > it will come up in normal accessible mode but missing the log records from > that last WAL file. > > This is a bug in our code which we will fix, but I am wondering if it > means there is a possibility > of worse than missing some updates. I.e. could it result in this > was-standby cluster now having > a corrupt database (e.g. an index entry with no matching heap slot or > something like that - or worse)? > > I think the question is whether the end of a WAL file is a point of > consistency? > like the timestamp you can specify in the recovery.conf for a > point-in-time recovery? > Or does postgresql xlogger just chop each WAL segment at the physical page > boundary? > > Cheers, John Lumby > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
