Thread: pgsql-server/src backend/access/transam/xact.c ...
CVSROOT: /cvsroot Module name: pgsql-server Changes by: tgl@svr1.postgresql.org 04/02/11 18:55:27 Modified files: src/backend/access/transam: xact.c xlog.c xlogutils.c src/backend/storage/smgr: md.c smgr.c src/bin/pg_controldata: pg_controldata.c src/bin/pg_resetxlog: pg_resetxlog.c src/include/access: xact.h xlog.h xlogutils.h src/include/catalog: pg_control.h src/include : pg_config_manual.h src/include/storage: smgr.h Log message: Commit the reasonably uncontroversial parts of J.R. Nield's PITR patch, to wit: Add a header record to each WAL segment file so that it can be reliably identified. Avoid splitting WAL records across segment files (this is not strictly necessary, but makes it simpler to incorporate the header records). Make WAL entries for file creation, deletion, and truncation (as foreseen but never implemented by Vadim). Also, add support for making XLOG_SEG_SIZE configurable at compile time, similarly to BLCKSZ. Fix a couple bugs I introduced in WAL replay during recent smgr API changes. initdb is forced due to changes in pg_control contents.
> Commit the reasonably uncontroversial parts of J.R. Nield's PITR patch, to > wit: Add a header record to each WAL segment file so that it can be reliably > identified. Avoid splitting WAL records across segment files (this is not > strictly necessary, but makes it simpler to incorporate the header records). > Make WAL entries for file creation, deletion, and truncation (as foreseen but > never implemented by Vadim). Also, add support for making XLOG_SEG_SIZE > configurable at compile time, similarly to BLCKSZ. Fix a couple bugs I > introduced in WAL replay during recent smgr API changes. initdb is forced > due to changes in pg_control contents. Is it worth adding one of those readonly GUC vars for XLOG_SEG_SIZE then? Chris
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes: > Is it worth adding one of those readonly GUC vars for XLOG_SEG_SIZE then? [shrug...] Maybe. I just did it because we've seen one or two requests about whether the size of the WAL overhead can be reduced for small installations. I'm not sure it's something people will do regularly. regards, tom lane