|From:||Venkata B Nagothi <nag1010(at)gmail(dot)com>|
|To:||Stephen Frost <sfrost(at)snowman(dot)net>|
|Cc:||Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: patch proposal|
|Views:||Raw Message | Whole Thread | Download mbox|
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
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
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.
Venkata B N
|Next Message||Craig Ringer||2016-11-08 22:54:03||Re: WIP: About CMake v2|
|Previous Message||Robert Haas||2016-11-08 22:33:48||Re: Do we need use more meaningful variables to replace 0 in catalog head files?|