Hannu Krosing wrote: > ?hel kenal p?eval, L, 2006-04-15 kell 11:49, kirjutas Tom Lane: > > Hannu Krosing <[EMAIL PROTECTED]> writes: > > > If I'm desperate enough to get the 2x reduction of WAL writes, I may > > > even write my own backup solution. > > > > Given Florian's concern, sounds like you might have to write your own > > kernel too. In which case, generating a variant build of Postgres > > that allows full_page_writes to be disabled is certainly not beyond > > your powers. But for the ordinary mortal DBA, I think this combination > > is just too unsafe to even consider. > > 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. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
