Re: changeset generation v5-01 - Patches & git tree

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Kevin Grittner <kgrittn(at)ymail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: changeset generation v5-01 - Patches & git tree
Date: 2013-07-10 21:33:18
Message-ID: 20130710213318.GB27898@alap2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-07-10 12:21:23 -0700, Kevin Grittner wrote:
> Sorry for the delay in reviewing this.  I must make sure never to
> take another vacation during a commitfest -- the backlog upon
> return is a killer....

Heh. Yes. Been through it before...

> Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:
> > Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>
> >> Otherwise, could you try applying my git tree so we are sure we
> >> test the same thing?
> >>
> >> $ git remote add af git://git.postgresql.org/git/users/andresfreund/postgres.git
> >> $ git fetch af
> >> $ git checkout -b xlog-decoding af/xlog-decoding-rebasing-cf4
> >> $ ./configure ...
> >> $ make
> >
> > Tried that, too, and problem persists.  The log shows the last
> > commit on your branch as 022c2da1873de2fbc93ae524819932719ca41bdb.
>
> The good news: the regression tests now work for me, and I'm back
> on testing this at a high level.

> The bad news:
>
> (1)  The code checked out from that branch does not merge with
> master.  Not surprisingly, given the recent commits, xlog.c is a
> problem.  Is there another branch I should now be using?  If not,
> please let me know when I can test with something that applies on
> top of the master branch.

That one is actually relatively easy to resolve. The mvcc catalog scan
patch is slightly harder. I've pushed an updated patch that fixes the
latter in a slightly not-so-nice way. I am not sure yet how the final
fix for that's going to look like, depends on whether we will get rid of
SnapshotNow alltogether...

I'll push my local tree with that fixed in a sec.

> (2)  An initial performance test didn't look very good.  I will be
> running a more controlled test to confirm but the logical
> replication of a benchmark with a lot of UPDATEs of compressed text
> values seemed to suffer with the logical replication turned on.
> Any suggestions or comments on that front, before I run the more
> controlled benchmarks?

Hm. There theoretically shouldn't actually be anything added in that
path. Could you roughly sketch what that test is doing? Do you actually
stream those changes out or did you just turn on wal_level=logical?

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 Josh Kupershmidt 2013-07-10 21:42:33 Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist
Previous Message Alvaro Herrera 2013-07-10 21:20:17 SSL renegotiation