Thread: pgsql: Merge the various forms of transaction commit & abort records.

Merge the various forms of transaction commit & abort records.

Since 465883b0a two versions of commit records have existed. A compact
version that was used when no cache invalidations, smgr unlinks and
similar were needed, and a full version that could deal with all
that. Additionally the full version was embedded into twophase commit
records.

That resulted in a measurable reduction in the size of the logged WAL in
some workloads. But more recently additions like logical decoding, which
e.g. needs information about the database something was executed on,
made it applicable in fewer situations. The static split generally made
it hard to expand the commit record, because concerns over the size made
it hard to add anything to the compact version.

Additionally it's not particularly pretty to have twophase.c insert
RM_XACT records.

Rejigger things so that the commit and abort records only have one form
each, including the twophase equivalents. The presence of the various
optional (in the sense of not being in every record) pieces is indicated
by a bits in the 'xinfo' flag.  That flag previously was not included in
compact commit records. To prevent an increase in size due to its
presence, it's only included if necessary; signalled by a bit in the
xl_info bits available for xact.c, similar to heapam.c's
XLOG_HEAP_OPMASK/XLOG_HEAP_INIT_PAGE.

Twophase commit/aborts are now the same as their normal
counterparts. The original transaction's xid is included in an optional
data field.

This means that commit records generally are smaller, except in the case
of a transaction with subtransactions, but no other special cases; the
increase there is four bytes, which seems acceptable given that the more
common case of not having subtransactions shrank.  The savings are
especially measurable for twophase commits, which previously always used
the full version; but will in practice only infrequently have required
that.

The motivation for this work are not the space savings and and
deduplication though; it's that it makes it easier to extend commit
records with additional information. That's just a few lines of code
now; without impacting the common case where that information is not
needed.

Discussion: 20150220152150.GD4149@awork2.anarazel.de,
    235610.92468.qm%40web29004.mail.ird.yahoo.com

Reviewed-By: Heikki Linnakangas, Simon Riggs

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/4f1b890b1377744688e43218f975d3c8b2ae39f8

Modified Files
--------------
src/backend/access/rmgrdesc/xactdesc.c   |  245 ++++++++++-----
src/backend/access/transam/twophase.c    |   59 +---
src/backend/access/transam/xact.c        |  475 ++++++++++++++++++------------
src/backend/access/transam/xlog.c        |  126 ++++----
src/backend/replication/logical/decode.c |  133 +++------
src/include/access/xact.h                |  215 ++++++++++----
src/include/access/xlog_internal.h       |    2 +-
7 files changed, 748 insertions(+), 507 deletions(-)

On Mon, Mar 16, 2015 at 1:38 AM, Andres Freund <andres@anarazel.de> wrote:
> Merge the various forms of transaction commit & abort records.

Coverity is complaining about the following block of code:
+       xact_info = XLogRecGetInfo(record) & XLOG_XACT_COMMIT;
+
+       if (xact_info != XLOG_XACT_COMMIT &&
+               xact_info != XLOG_XACT_COMMIT_PREPARED)
                return false;

Instead of XLOG_XACT_COMMIT, shouldn't this function use XLOG_XACT_OPMASK?
--
Michael

On 2015-03-23 13:04:09 +0900, Michael Paquier wrote:
> On Mon, Mar 16, 2015 at 1:38 AM, Andres Freund <andres@anarazel.de> wrote:
> > Merge the various forms of transaction commit & abort records.
>
> Coverity is complaining about the following block of code:
> +       xact_info = XLogRecGetInfo(record) & XLOG_XACT_COMMIT;
> +
> +       if (xact_info != XLOG_XACT_COMMIT &&
> +               xact_info != XLOG_XACT_COMMIT_PREPARED)
>                 return false;
>
> Instead of XLOG_XACT_COMMIT, shouldn't this function use XLOG_XACT_OPMASK?

That's a neat catch (by you and coverity). I wish we had automated test
infrastructure for this stuff (hint hint ;)). It's hard to remember to
test both normal and prepared xacts in all of the different scenarios.

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services