From: | Jacob Burroughs <jburroughs(at)instructure(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jelte Fennema-Nio <me(at)jeltef(dot)nl>, Dave Cramer <davecramer(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org> |
Subject: | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs |
Date: | 2024-05-17 17:26:45 |
Message-ID: | CACzsqT7WA03Y95B7Ja6u+-nPpZVirX5kZGFXhc=GW4gyYLEYVw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 17, 2024 at 3:15 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> OK, so you made it so that compressed data is fully self-identifying.
> Hence, there's no need to worry if something gets changed: the
> receiver, if properly implemented, can't help but notice. The only
> downside that I can see to this design is that you only have one byte
> to identify the compression algorithm, but that doesn't actually seem
> like a real problem at all, because I expect the number of supported
> compression algorithms to grow very slowly. I think it would take
> centuries, possibly millenia, before we started to get short of
> identifiers. So, cool.
>
> But, in your system, how does the client ask the server to switch to a
> different compression algorithm, or to restart the compression stream?
I was leaving the details around triggering that for this conversation
and in that patch just designing the messages in a way that would
allow adding the reconfiguration/restarting to be easily added in a
backwards-compatible way in a future patch. I would imagine that an
explicit `ParameterSet` call that sets `_pq_.connection_compression`
(or whatever the implementation details turn out to be) would also
trigger a compressor restart, and when restarted it would pick an
algorithm/configuration based on the new value of the parameter rather
than the one used at connection establishment.
--
Jacob Burroughs | Staff Software Engineer
E: jburroughs(at)instructure(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2024-05-17 17:41:19 | Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index. |
Previous Message | Peter Geoghegan | 2024-05-17 17:25:21 | Re: broken tables on hot standby after migration on PostgreSQL 16 (3x times last month) |