Message-ID: <87bb6850-1a9c-4f78-948e-44efade98443@pgmasters.net>
Date: Sat, 18 Nov 2023 09:30:01 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Use of backup_label not noted in log
Content-Language: en-US
To: Laurenz Albe <laurenz.albe@cybertec.at>,
 Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org,
 Michael Paquier <michael.paquier@gmail.com>
References: <20231117041811.vz4vgkthwjnwp2pp@awork3.anarazel.de>
 <c277c9736ec951776aa11a8ca95b60aaffbe8b8d.camel@cybertec.at>
From: David Steele <david@pgmasters.net>
In-Reply-To: <c277c9736ec951776aa11a8ca95b60aaffbe8b8d.camel@cybertec.at>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/87bb6850-1a9c-4f78-948e-44efade98443%40pgmasters.net>
Precedence: bulk

On 11/17/23 01:41, Laurenz Albe wrote:
> On Thu, 2023-11-16 at 20:18 -0800, Andres Freund wrote:
>> I've often had to analyze what caused corruption in PG instances, where the
>> symptoms match not having had backup_label in place when bringing on the
>> node. However that's surprisingly hard - the only log messages that indicate
>> use of backup_label are at DEBUG1.
>>
>> Given how crucial use of backup_label is and how frequently people do get it
>> wrong, I think we should add a LOG message - it's not like use of backup_label
>> is a frequent thing in the life of a postgres instance and is going to swamp
>> the log.  And I think we should backpatch that addition.
> 
> +1
> 
> I am not sure about the backpatch: it is not a bug, and we should not wantonly
> introduce new log messages in a minor release.  Some monitoring system may
> get confused.
> 
> What about adding it to the "redo starts at" message, something like
> 
>    redo starts at 12/12345678, taken from control file
> 
> or
> 
>    redo starts at 12/12345678, taken from backup label

I think a backpatch is OK as long as it is a separate message, but I 
like your idea of adding to the "redo starts" message going forward.

I know this isn't really a bug, but not being able to tell where 
recovery information came from seems like a major omission in the logging.

Regards,
-David