On Tue, Apr 11, 2017 at 10:13 PM, Noah Misch wrote:
> On Tue, Apr 11, 2017 at 11:33:34AM -0400, Tom Lane wrote:
>> Peter Eisentraut writes:
>> > I think there is no clear agreement here, and no historically consistent
>> > behavior. I'm
"David G. Johnston" writes:
> On Tue, Apr 11, 2017 at 11:10 AM, Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
>> On 4/11/17 11:47, David G. Johnston wrote:
>>> A potential middle-ground is to start, but then only allow superuser
>>> connections.
>>
On Mon, Apr 10, 2017 at 11:22:38PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Mon, Apr 10, 2017 at 09:36:59PM -0400, Peter Eisentraut wrote:
> >> If history had been different, we could have implemented, say,
> >> autovacuum or walreceiver on the background worker
On Tue, Apr 11, 2017 at 11:33:34AM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > I think there is no clear agreement here, and no historically consistent
> > behavior. I'm prepared to let it go and cross it off the list of open
> > items. I believe we
On Tue, Apr 11, 2017 at 11:10 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 4/11/17 11:47, David G. Johnston wrote:
> > A potential middle-ground is to start, but then only allow superuser
> > connections.
>
> Then you might as well start and allow all connections. I
On 4/11/17 11:47, David G. Johnston wrote:
> A potential middle-ground is to start, but then only allow superuser
> connections.
Then you might as well start and allow all connections. I don't see
what this buys.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL
On Tue, Apr 11, 2017 at 8:33 AM, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 4/10/17 23:22, Tom Lane wrote:
> >> Personally I'd err on the side of "starting up degraded is better than
> >> not starting at all". Or maybe we should
Peter Eisentraut writes:
> On 4/10/17 23:22, Tom Lane wrote:
>> Personally I'd err on the side of "starting up degraded is better than
>> not starting at all". Or maybe we should invent a GUC to let DBAs
>> express their preference on that?
> If we defaulted
On 4/10/17 23:22, Tom Lane wrote:
> Personally I'd err on the side of "starting up degraded is better than
> not starting at all". Or maybe we should invent a GUC to let DBAs
> express their preference on that?
If we defaulted allow_degraded to yes, then users wouldn't find that
setting until
Noah Misch writes:
> On Mon, Apr 10, 2017 at 09:36:59PM -0400, Peter Eisentraut wrote:
>> If history had been different, we could have implemented, say,
>> autovacuum or walreceiver on the background worker framework. I think
>> unifying some of that might actually be a future
On Mon, Apr 10, 2017 at 09:36:59PM -0400, Peter Eisentraut wrote:
> On 4/9/17 22:40, Noah Misch wrote:
> > Agreed. There are times when starting up degraded beats failing to start,
> > particularly when the failing component has complicated dependencies. In
> > this
> > case, as detailed
On 4/9/17 22:40, Noah Misch wrote:
> Agreed. There are times when starting up degraded beats failing to start,
> particularly when the failing component has complicated dependencies. In this
> case, as detailed upthread, this can only fail in response to basic
> misconfiguration. It's not the
On Wed, Mar 29, 2017 at 04:58:40PM -0300, Alvaro Herrera wrote:
> Robert Haas wrote:
> > On Wed, Mar 29, 2017 at 2:10 PM, Peter Eisentraut
> > wrote:
> > > How specifically would we do that? And what user would choose the
> > > behavior "start this background
Robert Haas wrote:
> On Wed, Mar 29, 2017 at 2:10 PM, Peter Eisentraut
> wrote:
> > How specifically would we do that? And what user would choose the
> > behavior "start this background worker but don't worry if it doesn't work"?
>
> Well, if the background
On Wed, Mar 29, 2017 at 2:10 PM, Peter Eisentraut
wrote:
> How specifically would we do that? And what user would choose the
> behavior "start this background worker but don't worry if it doesn't work"?
Well, if the background worker is auto-prewarm, you'd
On 3/24/17 02:33, Michael Paquier wrote:
> What if we just let the user choose what they want with a new switch
> in bgw_flags, but keep LOG the default? One behavior and the other
> look both sensible to me.
How specifically would we do that? And what user would choose the
behavior "start this
On Fri, Mar 24, 2017 at 1:20 PM, Peter Eisentraut
wrote:
> On 2/15/17 12:11, Robert Haas wrote:
>> On Wed, Feb 15, 2017 at 11:30 AM, Peter Eisentraut
>> wrote:
>>> If RegisterBackgroundWorker() (the non-dynamic kind that is only
On 2/15/17 12:11, Robert Haas wrote:
> On Wed, Feb 15, 2017 at 11:30 AM, Peter Eisentraut
> wrote:
>> If RegisterBackgroundWorker() (the non-dynamic kind that is only
>> loadable from shared_preload_libraries) fails to register the worker, it
>> writes a log
On Wed, Feb 15, 2017 at 11:30 AM, Peter Eisentraut
wrote:
> If RegisterBackgroundWorker() (the non-dynamic kind that is only
> loadable from shared_preload_libraries) fails to register the worker, it
> writes a log message and proceeds, ignoring the registration
If RegisterBackgroundWorker() (the non-dynamic kind that is only
loadable from shared_preload_libraries) fails to register the worker, it
writes a log message and proceeds, ignoring the registration request. I
think that is a mistake, it should be a hard error. The only way in
practice to fix
20 matches
Mail list logo