Re: Turning recovery.conf into GUCs

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: Turning recovery.conf into GUCs
Дата
Msg-id 54B715E9.2010508@agliodbs.com
обсуждение исходный текст
Ответ на Re: Turning recovery.conf into GUCs  (Jaime Casanova <jaime@2ndquadrant.com>)
Список pgsql-hackers
On 01/15/2015 02:24 AM, Robert Haas wrote:
> I think your idea of adding read-only GUCs with the same names as all
> of the recovey.conf parameters is a clear win.  Even if we do nothing
> more than that, it makes the values visible from the SQL level, and
> that's good.  But I think we should go further and make them really be
> GUCs.  Otherwise, if you want to be able to change one of those
> parameters other than at server startup time, you've got to invent a
> separate system for reloading them on SIGHUP.  If you make them part
> of the GUC mechanism, you can use that.  I think it's quite safe to
> say that the whole reason we *have* a GUC mechanism is so that all of
> our configuration can be done through one grand, unified mechanism
> rather than being fragmented across many files.

+1

I do find it ironic that the creator of the Grand Unified Configuration
Settings is arguing against unifying the files.

> Some renaming might be in order.  Heikki previously suggested merging
> all of the recovery_target_whatever settings down into a single
> parameter recovery_target='kindofrecoverytarget furtherdetailsgohere',
> like recovery_target='xid 1234' or recovery_target='name bob'.  Maybe
> that would be more clear (or not). 

Not keen on non-atomic settings, personally.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



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

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: hung backends stuck in spinlock heavy endless loop
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: hung backends stuck in spinlock heavy endless loop