Attached is the 2nd version of the patch with some enhancements. *Scenario 2 :* > > Generates Errors, Hints when the specified recovery target is prior to the > backup's current position (xid, time and lsn). This behaviour is integrated > with the parameters "recovery_target_time","recovery_target_lsn" and > "recovery_target_xid". >
In the second version of the patch, recovery_target_xid will be compared with the "latestCompletedXid" instead of "oldestXid" of the backup and if the specified recovery_target_xid is prior to the "latestCompletedXid" of the backup, then errors/hints would be generated indicating the DBA to use the appropriate backup. Now, with this patch, pg_controldata also displays the "latestCompletedXid" of the cluster. > Backup started at: 4/22D3B8E0, time: 2016-08-26 08:29:08 >>> Backup completed (consistency) at: 4/22D3B8EF, 2016-08-26 08:30:00 >>> recovery_target is not set >>> recovery_target_time = 2016-08-26 08:29:30 >>> recovery_target_inclusive = false >>> >>> In such a case, we will necessairly commit transactions which happened >>> between 8:29:30 and 8:30:00 and only stop (I believe..) once we've >>> reached consistency. We could possibly detect that case and throw an >>> error instead. The same could happen with xid. >>> >> >> Yes, currently, PG just recovers until the consistency is reached. It >> makes sense to throw an error instead. >> > > This has not been addressed yet. Currently, the patch only considers > generating an error if the recovery target position is prior the current > backup's position and this is irrespective of weather backup_label is > present or not. > I will share my updates on how this can be addressed. > This does not seem to be a possibility as the information in the backup_label is not enough to handle this scenario in specific cases like xid or time and it does not seem possible to add the backup stop info to the backup_label. I would prefer leaving this to the original behaviour at the moment which is : PostgreSQL generates errors and exits when *EndOfLog < minRecoveryPoint *during recovery Documentation is still pending from my end and will be submitting the same when the patch design/approach is agreed. Regards, Venkata B N Database Consultant Fujitsu Australia
recoveryTargetIncomplete.patch-version2
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers