Re: Return pg_control from pg_backup_stop(). - Mailing list pgsql-hackers

From David Steele
Subject Re: Return pg_control from pg_backup_stop().
Date
Msg-id 4771ba04-ca9d-4bd0-be09-14bbb9243e33@pgbackrest.org
Whole thread
In response to Re: Return pg_control from pg_backup_stop().  (shihao zhong <zhong950419@gmail.com>)
List pgsql-hackers
Hi Andrew and Shihao,

On 9/16/26 07:14, shihao zhong wrote:
> 
> Tested v13 on master (04c4c1c3a96). recovery, pg_rewind, pg_basebackup and
> regress all pass. Two comments.
> 
> 1. The pg_resetwal sentence in pg_basebackup.sgml
> 
> I asked for the field to be documented and still think it should be, but the
> wording offers pg_resetwal as a way out and it is not one.

Agreed, so added more cautionary language in v14.

> what is new is that users get sent there. Say what clears the flag, but make
> restoring backup_label the remedy. Also rename the "pg_resetwal clears the
> flag" subtest in 057.

I updated the comment but left the test message as is -- I think it 
works with the new comment.

> Separately, pg_resetwal never mentions backup_label in code or docs, and
> always leaves an unstartable cluster when one is present. A warning there
> would cut this off at the first step. Happy to post that as its own patch.

Yes, I think a separate patch would be best. Feel free to CC me so I can 
review.

> 2. The assert in backup_control_file()
> 
> Michael, this one is for you since David left the call to you. 

I went ahead and removed the assert since as Andrey showed it is 
demonstrably not correct. We'll see what Michael thinks.

Regards,
-David
Attachment

pgsql-hackers by date:

Previous
From: Radim Marek
Date:
Subject: Re: REPACK (CONCURRENTLY) can't complete after ~105M concurrent updates/deletes
Next
From: Etsuro Fujita
Date:
Subject: Re: Several issues with postgres_fdw stats import