Re: increasing the default WAL segment size
Michael Paquier <michael.paquier@gmail.com>
On Sun, Jan 8, 2017 at 9:52 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: >> I agree pretty_print_kb would have been a better for this function. >> However, I have realised that using the show hook and this function is >> not suitable and have found a better way of handling the removal of >> GUC_UNIT_XSEGS which no longer needs this function : using the >> GUC_UNIT_KB, convert the value in bytes to wal segment count instead in >> the assign hook. The next version of patch will use this. > > > ... it sounds like you're going back to exposing KB to users, and that's all > that really matters. > >> IMHO it'd be better to use the n & (n-1) check detailed at [3]. That would be better. So I am looking at the proposed patch, though there have been reviews the patch was in "Needs Review" state, and as far as I can see it is a couple of things for frontends. Just by grepping for XLOG_SEG_SIZE I have spotted the following problems: - pg_standby uses it to know about the next segment available. - pg_receivexlog still uses it in segment handling. It may be a good idea to just remove XLOG_SEG_SIZE and fix the code paths that fail to compile without it, frontend utilities included because a lot of them now rely on the value coded in xlog_internal.h, but with this patch the value is set up in the context of initdb. And this would induce major breakages in many backup tools, pg_rman coming first in mind... We could replace it with for example a macro that frontends could use to check if the size of the WAL segment is in a valid range if the tool does not have direct access to the Postgres instance (aka the size of the WAL segment used there) as there are as well offline tools. -#define XLogSegSize ((uint32) XLOG_SEG_SIZE) + +extern uint32 XLogSegSize; +#define XLOG_SEG_SIZE XLogSegSize This bit is really bad for frontend declaring xlog_internal.h... --- a/src/bin/pg_test_fsync/pg_test_fsync.c +++ b/src/bin/pg_test_fsync/pg_test_fsync.c @@ -62,7 +62,7 @@ static const char *progname; static int secs_per_test = 5; static int needs_unlink = 0; -static char full_buf[XLOG_SEG_SIZE], +static char full_buf[DEFAULT_XLOG_SEG_SIZE], This would make sense as a new option of pg_test_fsync. A performance study would be a good idea as well. Regarding the generic SHOW command in the replication protocol, I may do it for next CF, I have use cases for it in my pocket. -- Michael
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Make WAL segment size configurable at initdb time.
- fc49e24fa69a 11.0 landed
-
Perform only one ReadControlFile() during startup.
- 8356753c212a 11.0 landed
-
Introduce BYTES unit for GUCs.
- 6e7baa322773 11.0 landed
-
Remove useless duplicate inclusions of system header files.
- 9e3755ecb2d0 10.0 cited
-
Refactor other replication commands to use DestRemoteSimple.
- bbd8550bce14 10.0 landed
-
Add a SHOW command to the replication command language.
- d1ecd539477f 10.0 landed
-
Add a new DestReceiver for printing tuples without catalog access.
- a84069d93504 10.0 landed
-
Support fls().
- 4f658dc851a7 9.2.0 cited
-
Extend yesterday's patch making BLCKSZ and RELSEG_SIZE configurable to also
- cf9f6c8d8e9d 8.4.0 cited
-
Commit the reasonably uncontroversial parts of J.R. Nield's PITR patch, to
- c3c09be34b6b 8.0.0 cited
-
XLOG (also known as WAL -:)) Bootstrap/Startup/Shutdown.
- 47937403676d 7.1.1 cited
-
Transaction log manager core code.
- 30659d43eb73 7.1.1 cited