On 8/20/15 3:50 PM, Andres Freund wrote:
>> But, under any scheme to set wal_level automatically, how will the
>> primary know whether it needs to use level archive or hot_standby?
>
> I'd have said archive_mode triggered archive and everything else
> hot_standby.
That might be a decent heuristic
On 2015-08-20 15:11:02 -0400, Peter Eisentraut wrote:
> It seems to me that this would effectively replace the wal_level
> parameter with the presence or absence of a magic replication slot.
> That doesn't seem like a net improvement. It just replaces one
> well-known configuration mechanism with
On 8/19/15 9:32 AM, Andres Freund wrote:
>> I agree that we want both. But requiring a restart is a hard stop,
>> whereas making configuration easier is a soft feature.
>
> I don't think it makes that much of a difference for people new to
> postgres.
People new to postgres are not the only audi
On Wed, Aug 19, 2015 at 3:34 PM, Andres Freund wrote:
> On 2015-08-19 10:49:46 +0200, Magnus Hagander wrote:
> > What happens "the first time"? Meaning I'm on wal_level=minimal and take
> a
> > base backup. Then when the replica first connects 10 minutes later, it
> > needs WAL back in time, whic
On 2015-08-19 17:51:47 +0200, Magnus Hagander wrote:
> That's doable - but what about manual base backups? And if they don't go
> away, what about the ones that are generated by the
> nightly/weekly/hourly/whatever "pg_basebackup -x" ones?
Good questions. I guess we could just make do_pg_start_bac
On 2015-08-19 10:49:46 +0200, Magnus Hagander wrote:
> What happens "the first time"? Meaning I'm on wal_level=minimal and take a
> base backup. Then when the replica first connects 10 minutes later, it
> needs WAL back in time, which was logged at wal_level=minimal.
> So you'd need to bump it up
On 2015-08-18 21:47:51 -0400, Peter Eisentraut wrote:
> On 8/18/15 1:46 PM, Andres Freund wrote:
> > I don't think not requiring restarts is sufficient, having to twiddle a
> > bunch of parameters manually still is a lot more effort than people see
> > as necessary.
>
> I agree that we want both.
On 18 August 2015 at 18:46, Andres Freund wrote:
> ISTM that it's not too hard to
> a) make archive_mode PGC_SIGHUP
> b) make wal_level PGC_SIGHUP
>
+1
> c) automatically increase wal_level to logical whenever a logical
>replication slot is defined
>
-1
It would be easier to just have w
On Tue, Aug 18, 2015 at 7:46 PM, Andres Freund wrote:
> On 2015-08-18 13:24:54 -0400, Peter Eisentraut wrote:
> > On 8/18/15 12:35 PM, Robert Haas wrote:
> > > If archive_mode=on or max_wal_senders>0, then we need at least
> > > wal_level=archive. Otherwise wal_level=minimal is enough.
> >
> > T
On 8/18/15 1:46 PM, Andres Freund wrote:
> I don't think not requiring restarts is sufficient, having to twiddle a
> bunch of parameters manually still is a lot more effort than people see
> as necessary.
I agree that we want both. But requiring a restart is a hard stop,
whereas making configurat
On Wed, Aug 19, 2015 at 2:46 AM, Andres Freund wrote:
> On 2015-08-18 13:24:54 -0400, Peter Eisentraut wrote:
>> But if we tie the effective wal_level to archive_mode or
>> max_wal_senders, both of which are restart-only, then we haven't gained
>> anything. (We would have removed half a GUC param
On 2015-08-18 13:24:54 -0400, Peter Eisentraut wrote:
> On 8/18/15 12:35 PM, Robert Haas wrote:
> > If archive_mode=on or max_wal_senders>0, then we need at least
> > wal_level=archive. Otherwise wal_level=minimal is enough.
>
> Totally forgot about max_wal_senders.
>
> However, the thread I linke
On 8/18/15 12:35 PM, Robert Haas wrote:
> If archive_mode=on or max_wal_senders>0, then we need at least
> wal_level=archive. Otherwise wal_level=minimal is enough.
Totally forgot about max_wal_senders.
However, the thread I linked to earlier aimed for a different master
plan (or if not, I'm aim
On Tue, Aug 18, 2015 at 12:27 PM, Peter Eisentraut wrote:
> On 8/18/15 9:50 AM, Tom Lane wrote:
>> IIRC, the reason for having a wal_level parameter separate from those
>> other ones was precisely that only wal_level had to be PGC_POSTMASTER,
>> and you could change the others if you wanted.
>
> I
On 8/18/15 9:50 AM, Tom Lane wrote:
> IIRC, the reason for having a wal_level parameter separate from those
> other ones was precisely that only wal_level had to be PGC_POSTMASTER,
> and you could change the others if you wanted.
I think you are thinking of having split archive_mode/archive_comman
On Tue, Aug 18, 2015 at 9:50 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 8/18/15 8:48 AM, Robert Haas wrote:
>>> What do you mean by "prevent"? If the user edits postgresql.conf and
>>> reduces the setting, and then reloads the configuration file, they
>>> have a right to expect that th
Peter Eisentraut writes:
> On 8/18/15 8:48 AM, Robert Haas wrote:
>> What do you mean by "prevent"? If the user edits postgresql.conf and
>> reduces the setting, and then reloads the configuration file, they
>> have a right to expect that the changes got applied.
> We have certain checks in plac
On 8/18/15 8:48 AM, Robert Haas wrote:
> On Tue, Aug 18, 2015 at 7:59 AM, Peter Eisentraut wrote:
>> How would we handle decreases at run time? We can prevent >=archive ->
>> minimal if archiving is running or there are physical replication slots,
>> and we can prevent logical -> something less i
On Tue, Aug 18, 2015 at 7:59 AM, Peter Eisentraut wrote:
> How would we handle decreases at run time? We can prevent >=archive ->
> minimal if archiving is running or there are physical replication slots,
> and we can prevent logical -> something less if there are logical
> replication slots, but
On Tue, Aug 18, 2015 at 1:59 PM, Peter Eisentraut wrote:
> In [1], it was discussed to make wal_level changeable at run time
> (PGC_SIGHUP), as part of an effort to make replication easier to set up
> and/or provide better defaults. I was wondering what it would take to
> do that.
>
> I looks li
In [1], it was discussed to make wal_level changeable at run time
(PGC_SIGHUP), as part of an effort to make replication easier to set up
and/or provide better defaults. I was wondering what it would take to
do that.
I looks like increasing the setting is doable, as long as we WAL-log the
change
21 matches
Mail list logo
