Re: Libpq support to connect to standby server as priority

Поиск
Список
Период
Сортировка
От Haribabu Kommi
Тема Re: Libpq support to connect to standby server as priority
Дата
Msg-id CAJrrPGeaGJguFFRiWjuqae_2w1wt-PqUFE6QizHF+W9fkF4JGg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Libpq support to connect to standby server as priority  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Список 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.  
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Steele
Дата:
Сообщение: Re: Re: libpq compression
Следующее
От: David Steele
Дата:
Сообщение: Re: Re: Tid scan improvements