| From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, David Steele <david(at)pgmasters(dot)net>, Ildus Kurbangaliev <i(dot)kurbangaliev(at)gmail(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [HACKERS] Custom compression methods |
| Date: | 2021-03-07 08:06:50 |
| Message-ID: | CAFiTN-segDGMzDumGcQ-JyCryfAejq5hgRuqZLDiKoe-bQFS8g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Mar 7, 2021 at 12:47 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> > IMHO we can always allow creating the table with lz4 and only error
> > out when we really need to compress/decompress the data. I like this
> > behavior because it is the same as libxml. But I am fine with
> > allowing it only in binary upgrade also. Another option could be to
> > fall back to default "pglz" in binary upgrade mode if it is built
> > without-lz4 but the problem is this will change the table
> > specification after the upgrade.
>
> No, you certainly can't do that.
> You'd have a table defined as pglz but with lz4 in the data files.
> In the best case, it would give errors about corrupt lz4 data.
Yeah, we can not do that. Just missed that part :)
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tharakan, Robins | 2021-03-07 08:43:28 | RE: pg_upgrade failing for 200+ million Large Objects |
| Previous Message | Julien Rouhaud | 2021-03-07 07:39:36 | Re: pg_stat_statements oddity with track = all |