Re: allowing wal_level change at run time - Mailing list pgsql-hackers

From Andres Freund
Subject Re: allowing wal_level change at run time
Date
Msg-id 20150820195042.GC8552@awork2.anarazel.de
Whole thread Raw
In response to Re: allowing wal_level change at run time  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: allowing wal_level change at run time  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
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 a new ad hoc one.

Well, with the difference that it can be changed automatically. We could
alternatively automagically use ALTER SYSTEM, but that's not really
guaranteed to work and isn't available via the replication protocol
currently. But I could live with that as well.

> >> Also note that this scheme and any similar one requires merging the
> >> archive and hot_standby levels, which was the core of your original
> >> proposal [1]
> > 
> > It doesn't really, we could continue to keep them separate. I'm
> > proposing to maintain wal_level automatically, so it'd not be
> > configurable anymore, so it'd not matter much, as long as we're not less
> > efficient.
> 
> 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.  I am still of the opinion though that the difference
between those two levels is meaningless and that we should remove
archive.

Andres



pgsql-hackers by date:

Previous
From: Feng Tian
Date:
Subject: Re: Using quicksort for every external sort run
Next
From: Tomas Vondra
Date:
Subject: Re: DBT-3 with SF=20 got failed