Re: Cmpact commits and changeset extraction

On Mon, Sep 30, 2013 at 10:50 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> Changeset extraction only works in the context of a single database but
> has to scan through xlog records from multiple databases. Most records
> are easy to skip because they contain the database in the relfilenode or
> are just not interesting for logical replication. The only exception are
> compact commits.
> So we have some alternatives:
> 1) don't do anything, in that case empty transactions will get replayed since the changes
> themselves will get skipped.
> 2) Don't use compact commits if wal_level=logical
> 3) unify compact and non-compact commits, trying to get the normal one
> smaller.
>
> For 3) I am thinking of using 'xinfo' to store whether we have the other
> information or not. E.g. if there are subxacts in a compact commit we
> signal that by the flag 'XACT_COMMIT_CONTAINS_SUBXACTS' and store the
> number of subxacts after the xlog record. Similarly with relations,
> invalidation messages and the database id. That should leave compact
> commits without any subxacts at the former size, and those with at the
> former size + 4. Normal commits would get smaller in many cases since we
> don't store the empty fields.
>
> I personally think 3) is the best solution, any other opinions?

What's wrong with #1?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company