Re: Return value of pg_promote()

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Return value of pg_promote()
Date: 2023-06-07 16:25:38
Message-ID: 32454943-9f9e-dbb6-72e7-83c3462a21f2@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2023/06/07 2:00, Laurenz Albe wrote:
> On Tue, 2023-06-06 at 16:35 +0530, Ashutosh Sharma wrote:
>> At present, pg_promote() returns true to the caller on successful
>> promotion of standby, however it returns false in multiple scenarios
>> which includes:
>>
>> 1) The SIGUSR1 signal could not be sent to the postmaster process.
>> 2) The postmaster died during standby promotion.
>> 3) Standby couldn't be promoted within the specified wait time.
>>
>> For an application calling this function, if pg_promote returns false,
>> it is hard to interpret the reason behind it. So I think we should
>> *only* allow pg_promote to return false when the server could not be
>> promoted in the given wait time and in other scenarios it should just
>> throw an error (FATAL, ERROR ... depending on the type of failure that
>> occurred). Please let me know your thoughts on this change. thanks.!
>
> As the original author, I'd say that that sounds reasonable, particularly
> in case #1. If the postmaster dies, we are going to die too, so it
> probably doesn't matter much. But I think an error is certainly also
> correct in that case.

+1

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2023-06-07 17:05:39 Re: memory leak in trigger handling (since PG12)
Previous Message Yura Sokolov 2023-06-07 16:05:54 Re: Let's make PostgreSQL multi-threaded