Re: Block size with pg_dump?

On Aug 26, 2007, at 8:09 PM, Jean-David Beyer wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Bruce Momjian wrote:
>> Jean-David Beyer wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> When I make a backup of a database, I put the output file
>>> directly on
>>> magnetic tape; i.e., my command looks like this:
>>>
>>> pg_dump --file=/dev/st0 ....
>>>
>>> This way I do not have to worry if the total backup exceeds the
>>> size of a
>>> file system, and it saves me the trouble of copying it to the
>>> tape as a
>>> separate step. My current tapes will hold 20 GBytes raw or
>>> 40GBytes if I
>>> enable hardware compression (assuming 2:1 compression happens).
>>> Now it says
>>> in the documentation that if I use format c it will compress the
>>> data in
>>> software, so I doubt the hardware compression will do much.
>>>
>>> I do not know what blocksize pg_dump uses, or if it insists on a
>>> particular
>>> blocksize on input.
>>>
>>> Now my tape drive will work with any blocksize, but prefers 65536-
>>> byte
>>> blocks. I do not see any options for this in pg_dump, but I could
>>> pipe the
>>> output of pg_dump through dd I suppose to make any blocksize I want.
>>>
>>> On the way back, likewise I could pipe the tape through dd before
>>> giving it
>>> to pg_restore.
>>>
>>> Does pg_dump care what blocksize it gets? If so, what is it?
>>
>> I assume you could pipe pg_dump into dd and specify the block size in
>> dd.
>>
> Of course on the way out I can do that.
>
> The main question is, If I present pg_restore with a 65536-byte
> blocksize
> and it is expecting, e.g., 1024-bytes, will the rest of each block get
> skipped? I.e., do I have to use dd on the way back too? And if so,
> what
> should the blocksize be?

Postgres (by default) uses 8K blocks.

Erik Jones

Software Developer | Emma®
erik(at)myemma(dot)com
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com