Re: Libpq support to connect to standby server as priority

On Fri, Mar 22, 2019 at 6:07 PM Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
wrote:

>
> On Fri, Mar 22, 2019 at 7:32 AM Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
> wrote:
>
>>
>> On Fri, Mar 22, 2019 at 6:57 AM Robert Haas <robertmhaas(at)gmail(dot)com>
>> wrote:
>>
>>> On Thu, Mar 21, 2019 at 2:26 AM Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
>>> wrote:
>>> > Based on the above new options that can be added to
>>> target_session_attrs,
>>> >
>>> > primary - it is just an alias to the read-write option.
>>> > standby, prefer-standby - These options should check whether server is
>>> running in recovery mode or not
>>> > instead of checking whether server accepts read-only connections or
>>> not?
>>>
>>> I think it will be best to have one set of attributes that check
>>> default_transaction_read_only and a differently-named set that check
>>> pg_is_in_recovery(). For each, there should be one value that looks
>>> for a 'true' return and one value that looks for a 'false' return and
>>> perhaps values that accept either but prefer one or the other.
>>>
>>> IOW, there's no reason to make primary an alias for read-write. If
>>> you want read-write, you can just say read-write. But we can make
>>> 'primary' or 'master' look for a server that's not in recovery and
>>> 'standby' look for one that is.
>>>
>>
>> OK, I agree with opinion. I will produce a patch for those new options.
>>
>
> Here I attached WIP patch for the new options along with other older
> patches.
> The basic cases are working fine, doc and tests are missing.
>
> Currently this patch doesn't implement the GUC_REPORT for recovery mode
> yet. I am yet to optimize the complex if check.
>

Except in_hotstandby GUC_REPORT, rest of the changes are implemented.
Updated patches are attached.

while going through the old patch where the GUC_REPORT is implemented,
Tom has commented the logic of sending the signal to all backends to process
the hot standby exit with SIGHUP, if we add the logic of updating the GUC
variable value in SIGHUP, we may need to change all the SIGHUP handler
code paths. It is also possible that there is no need to update the
variable for
other processes except backends.

If we go with adding the new SIGUSR1 type to check and update the GUC
varaible
can work for most of the backends and background workers.

opinions

Regards,
Haribabu Kommi
Fujitsu Australia

Note - Attachments order may sometime go wrong.