On 2013-09-30 14:22:22 -0400, Robert Haas wrote: > On Mon, Sep 30, 2013 at 10:50 AM, Andres Freund <and...@2ndquadrant.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?
It seems confusing that a changeset stream in database #1 will contain commits (without corresponding changes) from database #2. Seems like aaa pola violation to me. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers