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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: changeset generation v5-01 - Patches & git tree
Дата
Msg-id 20130710213318.GB27898@alap2.anarazel.de
обсуждение исходный текст
Ответ на Re: changeset generation v5-01 - Patches & git tree  (Kevin Grittner <kgrittn@ymail.com>)
Ответы Re: changeset generation v5-01 - Patches & git tree  (Kevin Grittner <kgrittn@ymail.com>)
Список 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@ymail.com> wrote:
> > Andres Freund <andres@2ndquadrant.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: SSL renegotiation
Следующее
От: Josh Kupershmidt
Дата:
Сообщение: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist