|From:||Beena Emerson <memissemerson(at)gmail(dot)com>|
|To:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>|
|Cc:||Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, David Steele <david(at)pgmasters(dot)net>, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, Prabhat Sahu <prabhat(dot)sahu(at)enterprisedb(dot)com>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>|
|Subject:||Re: increasing the default WAL segment size|
|Views:||Raw Message | Whole Thread | Download mbox|
On Tue, Mar 28, 2017 at 1:06 AM, Beena Emerson <memissemerson(at)gmail(dot)com> wrote:
> On Sat, Mar 25, 2017 at 10:32 PM, Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>> At this point, I suggest splitting this patch up into several
>> potentially less controversial pieces.
>> One big piece is that we currently don't support segment sizes larger
>> than 64 GB, for various internal arithmetic reasons. Your patch appears
>> to address that. So I suggest isolating that. Assuming it works
>> correctly, I think there would be no great concern about it.
>> The next piece would be making the various tools aware of varying
>> segment sizes without having to rely on a built-in value.
>> The third piece would then be the rest that allows you to set the size
>> at initdb
>> If we take these in order, we would make it easier to test various sizes
>> and see if there are any more unforeseen issues when changing sizes. It
>> would also make it easier to do performance testing so we can address
>> the original question of what the default size should be.
> PFA the patches divided into 3 parts:
> 02-increase-max-wal-segsize.patch - Increases the wal-segsize and changes
> the internal representation of max_wal_size and min_wal_size to mb.
> 03-modify-tools.patch - Makes XLogSegSize into a variable, currently set as
> XLOG_SEG_SIZE and modifies the tools to fetch the size instead of using
> inbuilt value.
The updated 03-modify-tools_v2.patch has the following changes:
- Rebased over current HEAD
- Impoverished comments
- Adding error messages where applicable.
- Replace XLOG_SEG_SIZE in the tools and xlog_internal.h to
XLogSegSize. XLOG_SEG_SIZE is the wal_segment_size the server was
compiled with and XLogSegSize is the wal_segment_size of the target
server on which the tool is run. When the binaries used and the target
server are compiled with different wal_segment_size, the calculations
would be be affected and the tool would crash. To avoid it, all the
calculations used by tool should use XLogSegSize.
- pg_waldump : The fuzzy_open_file is split into two functions -
open_file_in_directory and identify_target_directory so that code can
be reused when determining the XLogSegSize from the WAL file header.
- IsValidXLogSegSize macro is moved from 04 to here so that we can
use it for validating the size in all the tools.
> 04-initdb-walsegsize.patch - Adds the initdb option to set wal-segsize and
> make related changes. Update pg_test_fsync to use DEFAULT_XLOG_SEG_SIZE
> instead of XLOG_SEG_SIZE
The 04-initdb-walsegsize_v2.patch has the following improvements:
- Rebased over new 03 patch
- Pass the wal-segsize intidb option as command-line option rathern
than in an environment variable.
- Since new function check_wal_size had only had two checks and was
sed once, moved the code to ReadControlFile where it is used and
removed this function.
- improve comments and add validations where required.
- Use DEFAULT_XLOG_SEG_SIZE to set the min_wal_size and
max_wal_size,instead of the value 16.
- Use XLogSegMaxSize and XLogSegMinSize to calculate the range of guc
wal_segment_size instead 16 - INT_MAX.
>> One concern I have is that your patch does not contain any tests. There
>> should probably be lots of tests.
> 05-initdb_tests.patch adds tap tests to initialize cluster with different
> wal_segment_size and then check the config values. What other tests do you
> have in mind? Checking the various tools?
The Enterprise PostgreSQL Company
|Next Message||Etsuro Fujita||2017-07-06 06:58:40||Re: Update comment in ExecPartitionCheck|
|Previous Message||Amit Kapila||2017-07-06 06:08:20||Re: Proposal : For Auto-Prewarm.|