From: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
To: Andres Freund <andres@anarazel.de>
Cc: Iwata, Aya <iwata.aya@jp.fujitsu.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: rharwood@redhat.com <rharwood@redhat.com>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: g.smolkin@postgrespro.ru <g.smolkin@postgrespro.ru>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>
Subject: Re: libpq compression
Date: Sat, 9 Feb 2019 01:10:45 +0300
Message-ID: <512b537f-ca42-1f61-4f87-d7197949c455@postgrespro.ru> (raw)
In-Reply-To: <20190208185703.xy35plk7mb4ve57d@alap3.anarazel.de>
References: <CA+Tgmob08ikN03bZGgrf=nUAYkZ2-ZuRuWqP-BBkUq9v_AEw=Q@mail.gmail.com>
<8d9386be-a567-c526-2fc1-153d6ffd3507@2ndQuadrant.com>
<17747c8b-c088-6f92-38e9-98316910202a@postgrespro.ru>
<20181001064903.GG11712@paquier.xyz>
<c79ff1a0-d2c7-c513-598e-f9658329654b@postgrespro.ru>
<CA+q6zcVaT=m-Py-R2ap0oZDEWxUkKR9hFqDpVNNtHTGTkbd75g@mail.gmail.com>
<71E660EB361DF14299875B198D4CE5423DEB752E@g01jpexmbkw25>
<1b2d418b-f3b1-620e-8456-145d6e943da6@postgrespro.ru>
<71E660EB361DF14299875B198D4CE5423DED67E5@g01jpexmbkw25>
<dae47f7a-9e33-8cba-859c-dbd39bebe218@postgrespro.ru>
<20190208185703.xy35plk7mb4ve57d@alap3.anarazel.de>
On 08.02.2019 21:57, Andres Freund wrote:
> On 2019-02-08 12:15:58 +0300, Konstantin Knizhnik wrote:
>> Frankly speaking, I do not think that such flexibility in choosing
>> compression algorithms is really needed.
>> I do not expect that there will be many situations where old client has to
>> communicate with new server or visa versa.
>> In most cases both client and server belongs to the same postgres
>> distributive and so implements the same compression algorithm.
>> As far as we are compressing only temporary data (traffic), the problem of
>> providing backward compatibility seems to be not so important.
> I think we should outright reject any patch without compression type
> negotiation.
Does it mean that it is necessary to support multiple compression
algorithms and make it possible to perform switch between them at
runtime? Right now compression algorithm is linked statically.
Negotiation of compression type is currently performed but it only
checks that server and client are implementing the same algorithm and
disables compression if it is not true.
If we are going to support multiple compression algorithms, do we need
dynamic loading of correspondent compression libraries or static linking
is ok? In case of dynamic linking we need to somehow specify information
about available compression algorithms.
Some special subdirectory for them so that I can traverse this directory
and try to load correspondent libraries?
Only I find it too complicated for the addressed problem?
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: k.knizhnik@postgrespro.ru, andres@anarazel.de, iwata.aya@jp.fujitsu.com, michael@paquier.xyz, andrew.dunstan@2ndquadrant.com, robertmhaas@gmail.com, rharwood@redhat.com, thomas.munro@enterprisedb.com, g.smolkin@postgrespro.ru, pgsql-hackers@lists.postgresql.org, 9erthalion6@gmail.com
Subject: Re: libpq compression
In-Reply-To: <512b537f-ca42-1f61-4f87-d7197949c455@postgrespro.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox