Re: pg_dump -Fd and compression level

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Marc Mamin <M(dot)Mamin(at)intershop(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump -Fd and compression level
Date: 2015-07-25 20:38:54
Message-ID: 55B3F3DE.9090705@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 07/25/2015 03:07 PM, Marc Mamin wrote:
>>> I propose to tighten pg_dump's rules so that only 0..9 are accepted as
>>> arguments for -Z, and in compress_io.c:cfopen(), if compression is
>>> equal to Z_DEFAULT_COMPRESSION, not add any explicit compression value
>>> to the mode, thus using the zlib default.
>>>
>>>
>>
>> As per attached patch.
>>
>> Comments?
>
> It seems that the first test on the compression in pg_backup_tar.c is now obsolete.
> It didn't make much sense anyway.
>
>
>
> 211 if (AH->compression < 0 || AH->compression > 9)
> 212 AH->compression = Z_DEFAULT_COMPRESSION;
> 213
> 214 /* Don't compress into tar files unless asked to do so */
> 215 if (AH->compression == Z_DEFAULT_COMPRESSION)
> 216 AH->compression = 0;
> 217
> 218 /*
> 219 * We don't support compression because reading the files back is not
> 220 * possible since gzdopen uses buffered IO which totally screws file
> 221 * positioning.
> 222 */
> 223 if (AH->compression != 0)
> 224 exit_horribly(modulename,
> 225 "compression is not supported by tar archive format\n");
> 226 }
>
>

In fact, the first two tests look unnecessary. Neither condition should
be possible now.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2015-07-25 20:55:32 Re: Debugging buildfarm pg_upgrade check failures
Previous Message Bill Moran 2015-07-25 20:25:46 Re: Anyone working on the TOAST items on the TODO list?