| From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz>, Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | gkokolatos(at)pm(dot)me, shiy(dot)fnst(at)fujitsu(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, Rachel Heaton <rachelmheaton(at)gmail(dot)com> |
| Subject: | Re: Add LZ4 compression in pg_dump |
| Date: | 2023-03-01 14:33:00 |
| Message-ID: | 5da177e0-42d3-9426-964e-858861c42e53@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 3/1/23 08:24, Michael Paquier wrote:
> On Tue, Feb 28, 2023 at 05:58:34PM -0600, Justin Pryzby wrote:
>> I found that e9960732a broke writing of empty gzip-compressed data,
>> specifically LOs. pg_dump succeeds, but then the restore fails:
>
> The number of issues you have been reporting here begins to worries
> me.. How many of them have you found? Is it right to assume that all
> of them have basically 03d02f5 as oldest origin point?
AFAICS a lot of the issues are more a discussion about wording in a
couple places, whether it's nicer to do A or B, name the functions
differently or what.
I'm aware of three genuine issues that I intend to fix shortly:
1) incorrect "if" condition in a TAP test
2) failure when compressing empty LO (which we had no test for)
3) change in handling "compression level = 0" (which I believe should be
made to behave like before)
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2023-03-01 14:57:45 | Re: POC: Lock updated tuples in tuple_update() and tuple_delete() |
| Previous Message | Melih Mutlu | 2023-03-01 14:28:23 | Re: Allow logical replication to copy tables in binary format |