Re: Add LZ4 compression in pg_dump
От | gkokolatos@pm.me |
---|---|
Тема | Re: Add LZ4 compression in pg_dump |
Дата | |
Msg-id | QUGD4N2_0ZAxEvmXq1C47ifO3VFvPKClogTb8pTgQaUDsqSel7rOzSr2DmPwdSU4GcHE5NgTXYpF518zHxC1diLOZ__HkB1pamU6klcMaW8=@pm.me обсуждение исходный текст |
Ответ на | Re: Add LZ4 compression in pg_dump (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: Add LZ4 compression in pg_dump
|
Список | pgsql-hackers |
------- Original Message ------- On Thursday, March 16th, 2023 at 11:30 PM, Tomas Vondra <tomas.vondra@enterprisedb.com> wrote: > > > > > On 3/16/23 01:20, Justin Pryzby wrote: > > > On Mon, Mar 13, 2023 at 10:47:12PM +0100, Tomas Vondra wrote: > > > > > > > > Thanks. I don't want to annoy you too much, but could you split the > > > patch into the "empty-data" fix and all the other changes (rearranging > > > functions etc.)? I'd rather not mix those in the same commit. > > > > I don't know if that makes sense? The "empty-data" fix creates a new > > function called DeflateCompressorInit(). My proposal was to add the new > > function in the same place in the file as it used to be. > > > Got it. In that case I agree it's fine to do that in a single commit. For what is worth, I think that this patch should get a +1 and get in. It solves the empty writes problem and includes a test to a previous untested case. Cheers, //Georgios > > > The patch also moves the pg_fatal() that's being removed. I don't think > > it's going to look any cleaner to read a history involving the > > pg_fatal() first being added, then moved, then removed. Anyway, I'll > > wait while the community continues discussion about the pg_fatal(). > > > I think the agreement was to replace the pg_fatal with and assert, and I > see your patch already does that. > > > regards > > -- > Tomas Vondra > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: