Re: patch proposal

Поиск
Список
Период
Сортировка
От Venkata B Nagothi
Тема Re: patch proposal
Дата
Msg-id CAEyp7J8VRjK9+DY=mLXYu2Xqu3A0-bFo71vMaoFB8rAPKmJo1w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: patch proposal  (Venkata B Nagothi <nag1010@gmail.com>)
Ответы Re: [HACKERS] patch proposal
Список pgsql-hackers
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
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: WIP: About CMake v2
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Do we need use more meaningful variables to replace 0 in catalog head files?