On 4/16/06, Bruce Momjian <pgman@candle.pha.pa.us> wrote:
> Hannu Krosing wrote:
> > I guess that writing our own pg_tar, which cooperates with postgres
> > backends to get full pages, is still in the realm of possible things,
> > even on kernels which dont guarantee atomic visibility of write() calls.
> >
> > But until such is included in the distribution it is a good idea indeed
> > to disable full_page_writes=off when doing PITR.
>
> The cost/benefit of that seems very discouraging. Most backup
> applications allow for a block size to be specified, so it isn't
> unreasonable to assume that people who really want PITR and
> full_page_writes can easily set the block size to 8k. However, I don't
> think we are going to allow that to be configured --- you would have to
> hack up our backend code to allow the combination.
The problem is that they allow configuring _target_ block size,
not reading block size. I did some tests with strace:
* GNU cpio version 2.5
allows to change only output block size, input block is 512
bytes. Maybe uses device's block size?
* tar (GNU tar) 1.15.1
the '-b' and '--record-size' options change also input block
size, but to get 8192 bytes for output block, the first read is 7680
bytes to make room for tar header. the rest of reads are indeed 8192
bytes, but that won't help us anymore.
* cp (coreutils) 5.2.1
fixed block size of 4096 bytes.
* rsync version 2.6.5
it does not have a way to change input block size. but it seems
that it reads with 32k blocks or full file if length < 32k.
So we should probably document that rsync is only working solution.
--
marko
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
