Re: Cmpact commits and changeset extraction

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Cmpact commits and changeset extraction
Date: 2013-10-01 11:26:01
Message-ID: 20131001112601.GG2670970@alap2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-10-01 06:20:20 -0400, Robert Haas wrote:
> On Mon, Sep 30, 2013 at 5:34 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> >> 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.
>
> I don't really see the problem. A transaction could be empty for lots
> of reasons; it may have obtained an XID without writing any data, or
> whatever it's changed may be outside the bounds of logical rep.

Sure. But all of them will have had a corresponding action in the
database. If your replication stream suddenly sees commits that you
cannot connect to any application activity... And it would depend on the
kind of commit, you won't see it if a non-compact commit was used.
It also means we need to do work to handle that commit. If you have a
busy and a less so database and you're only replicating the non-busy
one, that might be noticeable.

> 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"? If the user did a SELECT * FROM foo FOR
UPDATE, maybe it was done to coordinate stuff with the standby and the
knowledge about that commit is required?
It doesn't really seem "our" responsibility to detect that.

Greetings,

Andres Freund

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ants Aasma 2013-10-01 11:31:11 Re: [PERFORM] Cpu usage 100% on slave. s_lock problem.
Previous Message Andres Freund 2013-10-01 11:13:55 Re: Freezing without write I/O