Re: Cmpact commits and changeset extraction - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Cmpact commits and changeset extraction
Date
Msg-id CA+TgmoaDtLSOc9EdEg3g=H+A48wBtvP0hfkLzAEKJu-2dFbDrQ@mail.gmail.com
Whole thread Raw
In response to Re: Cmpact commits and changeset extraction  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Fri, Oct 11, 2013 at 4:05 PM, Andres Freund <andres@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Long paths for tablespace leads to uninterruptible hang in Windows
Next
From: Robert Haas
Date:
Subject: Re: background workers, round three