On 02/04/2015 12:06 PM, Robert Haas wrote:
> On Wed, Feb 4, 2015 at 1:05 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> Let me push "max_wal_size" and "min_wal_size" again as our new parameter
>> names, because:
>>
>> * does what it says on the tin
>> * new user friendly
>> * encourages people to express it in MB, not segments
>> * very different from the old name, so people will know it works differently
>
> That's not bad. If we added a hard WAL limit in a future release, how
> would that fit into this naming scheme?
Well, first, nobody's at present proposing a patch to add a hard limit,
so I'm reluctant to choose non-obvious names to avoid conflict with a
feature nobody may ever write. There's a number of reasons a hard limit
would be difficult and/or undesirable.
If we did add one, I'd suggest calling it "wal_size_limit" or something
similar. However, we're most likely to only implement the limit for
archives, which means that it might acually be called
"archive_buffer_limit" or something more to the point.
> That's certainly better, but I think we should go further. Again,
> you're not committed to using this space all the time, and if you are
> using it you must have a lot of write activity, which means you are
> not running on a tin can and a string. If you have a little tiny
> database, say 100MB, running on a little-tiny Amazon instance,
> handling a small number of transactions, you're going to stay close to
> wal_min_size anyway. Right?
Well, we can test that.
So what's your proposed size?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
