From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
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-07 23:59:54 |
Message-ID: | 18858.984009594@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
>> But what possible reason is there for keeping it in pg_control?
>> AFAICS that would just mean that we'd need special code for setting it,
>> instead of making use of all of Peter's hard work on GUC.
> I don't think it's appropriate to edit archdir by hand.
Why not? How is this a critical parameter (more critical than, say,
fsync enable)? I see no reason to forbid the administrator from
changing it ... indeed, I think an admin who found out he couldn't
change it on-the-fly would be justifiably unhappy. ("What do you
MEAN I can't change archdir? I'm about to run out of space in
/usr/logs/foobar!!!")
I agree that we don't want random users changing the value via SET and
then issuing a CHECKPOINT (which would use whatever they'd SET :-().
But that's easily managed by setting an appropriate protection level
on the GUC variable. Looks like SIGHUP level would be appropriate.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ian Lance Taylor | 2001-03-08 00:23:33 | Re: Proposed WAL changes |
Previous Message | Philip Warner | 2001-03-07 23:51:41 | Re: Performance monitor |