Re: libpq compression

From: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
To: David Steele <david(at)pgmasters(dot)net>
Cc: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Robbie Harwood <rharwood(at)redhat(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Grigory Smolkin <g(dot)smolkin(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: libpq compression
Date: 2019-03-25 10:48:00
Message-ID: CA+q6zcWC63iJye557H17biN05CR8PpuFYuOovH+RVwrTnqRz8g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Mon, Mar 25, 2019 at 11:39 AM David Steele <david(at)pgmasters(dot)net> wrote:
>
> On 3/25/19 1:04 PM, Konstantin Knizhnik wrote:
> >
> >
> > On 25.03.2019 11:06, David Steele wrote:
> >> Konstantin,
> >>
> >>
> >> This patch appears to be failing tests so I have marked it Waiting on
> >> Author.
> >>
> >> I have also removed the reviewer since no review had been done. Maybe
> >> somebody else will have a look.
> >>
> >> Regards,
> >
> > Can you please inform me which tests are failed?
> > I have done "make check-world" and there were no failed tests.
> > Actually if compression is not enabled (and it is disabled by default
> > unless explicitly requested by client), there should be no difference
> > with vanilla Postgres.
> > So it will be strange if some tests are failed without using compression.
>
> Check out the cfbot report at http://commitfest.cputube.org

I guess it's red because the last posted patch happened to be my experimental
patch (based indeed on a broken revision v11), not the one posted by Konstantin.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2019-03-25 10:49:42 Re: Usage of epoch in txid_current
Previous Message Peter Eisentraut 2019-03-25 10:44:26 Re: Speed up transaction completion faster after many relations are accessed in a transaction