| From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>, Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: AW: Proposed WAL changes |
| Date: | 2001-03-08 01:47:58 |
| Message-ID: | 3AA6E4CE.AFF9516A@tpf.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
>
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > Tom Lane wrote:
> >> Why not? How is this a critical parameter (more critical than, say,
> >> fsync enable)?
>
> > Does it have any meaning other than testing ? IMHO recovery system
> > doesn't allow any optimism and archdir is also a part of recovery
> > system though I'm not sure how critical the parameter would be.
>
> I still don't see your point. The admin *can* change these parameters
> if he wishes. Why should we make it more difficult to do so than is
> reasonably necessary? There is certainly no technical reason why we
> should (say) force an initdb to change archdir.
>
I've never objected to change archdir on the fly.
Though GUC is profitable for general purpose it
could(must)n't be almighty. As for recovery
we must rely on DBA as less as possible.
Hiroshi Inoue
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mikheev, Vadim | 2001-03-08 01:49:34 | RE: Proposed WAL changes |
| Previous Message | Philip Warner | 2001-03-08 01:25:59 | RE: Performance monitor |