Re: Cmpact commits and changeset extraction

On Fri, Oct 11, 2013 at 4:05 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> Maybe. The original reason we added compact commits was because we
>> thought that making unlogged tables logged and visca/versa was going
>> to require adding still more stuff to the commit record. I'm no
>> longer sure that's the case and, in any case, nobody's worked out the
>> design details. But I can't help thinking more stuff's likely to come
>> up in the future. I'm certainly willing to entertain proposals for
>> restructuring that, but I don't really want to just throw it out.
>
> Well, what I am thinking of - including & reading data depending on a
> flag in ->xinfo - would give you extensibility without requiring
> different types of commits. And it would only blow up the size by
> whatever needs to be included.

Hard to comment without seeing the patch. Sounds like it could be
reasonable, if it's not too ugly.

>> >> Maybe you should just skip replay of transactions with no useful
>> >> content.
>> >
>> > Yes, I have thought about that as well. But I dislike it - how do we
>> > define "no useful content"?
>>
>> The only action we detected for that XID was the commit itself.
>
> What if the transaction was intentionally done to get an xid + timestamp
> in a multimaster system? What if it includes DDL but no logged data? Do
> we replay a transaction because of the pg_shdepend entry when creating a
> table in another database?

None of these things seem particularly alarming to me. I don't know
whether that represents a failure of imagination on my part or undue
alarm on your part. :-)

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