Re: Libpq support to connect to standby server as priority - Mailing list pgsql-hackers

From Haribabu Kommi
Subject Re: Libpq support to connect to standby server as priority
Date
Msg-id CAJrrPGeaGJguFFRiWjuqae_2w1wt-PqUFE6QizHF+W9fkF4JGg@mail.gmail.com
Whole thread Raw
In response to Re: Libpq support to connect to standby server as priority  (Haribabu Kommi <kommi.haribabu@gmail.com>)
List pgsql-hackers

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

On Fri, Mar 22, 2019 at 7:32 AM Haribabu Kommi <kommi.haribabu@gmail.com> wrote:

On Fri, Mar 22, 2019 at 6:57 AM Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Mar 21, 2019 at 2:26 AM Haribabu Kommi <kommi.haribabu@gmail.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.  
Attachment

pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: Re: libpq compression
Next
From: David Steele
Date:
Subject: Re: Re: Tid scan improvements