On Tue, Mar 28, 2017 at 1:06 AM, Beena Emerson <memissemer...@gmail.com> wrote: > On Sat, Mar 25, 2017 at 10:32 PM, Peter Eisentraut > <peter.eisentr...@2ndquadrant.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: Thanks for splitting the patches. 01-add-XLogSegmentOffset-macro.patch is same as before and it looks good.
> 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. looks good. > 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. Several methods are declared and defined in different tools to fetch the size of wal-seg-size. In pg_standby.c, RetrieveXLogSegSize() - /* Set XLogSegSize from the WAL file header */ In pg_basebackup/streamutil.c, on behaRetrieveXLogSegSize(PGconn *conn) - /* set XLogSegSize using SHOW wal_segment_size */ In pg_waldump.c, ReadXLogFromDir(char *archive_loc) RetrieveXLogSegSize(char *archive_path) /* Scan through the archive location to set XLogSegsize from the first WAL file */ IMHO, it's better to define a single method in xlog.c and based on the different strategy, it can retrieve the XLogSegsize on behalf of different modules. I've suggested the same in my first set review and I'll still vote for it. For example, in xlog.c, you can define something as following: bool RetrieveXLogSegSize(RetrieveStrategy rs, void* ptr) Now based on the RetrieveStrategy(say Conn, File, Dir), you can cast the void pointer to the appropriate type. So, when a new tool needs to retrieve XLogSegSize, it can just call this function instead of defining a new RetrieveXLogSegSize method. It's just a suggestion from my side. Is there anything I'm missing which can cause the aforesaid approach not to be working? Apart from that, I've nothing to add here. > 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 looks good. >> >> 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? Nothing from me to add here. I've nothing to add here for the attached set of patches. On top of these, David's patch can be used for preserving LSNs in the file naming for all segment sizes. -- Thanks & Regards, Kuntal Ghosh EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers